Streaming and backend conditional requests
Poul-Henning Kamp
phk at phk.freebsd.dk
Sat Jan 14 20:10:41 CET 2012
In message <4F118990.7020702 at uplex.de>, Geoff Simmons writes:
>On 1/13/12 2:18 PM, Poul-Henning Kamp wrote:
>>
>> By default all backend fetches which can find a candidate for it,
>> will try to IMS against the backend. If you do not want that, you
>> remove the bereq.http.IMS header in vcl_pass{}/vcl_miss{}
>
>What got the conversation going about this is that in the current
>implementation, a busy object can never be the candidate for a
>validation. So in 3.0 streaming, it can never be an object that is
>still streaming. If that's the right solution now and in the future,
>then everything's fine.
Actually once Martins streaming is in, we will have three object
states:
busy
Not available for anybody but the fetching thread.
incomplete
We don't have the body yet, but can stream
complete
"unbusy" today.
I will argue that only "complete" objects are IMS candidates,
because they are the only ones we can serve, should we get an
affirmative answer from the backend.
I guess we could IMS "incomplete" also, but that sounds more
complicated and I would need to study it more.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the varnish-dev
mailing list