Streaming and backend conditional requests

Poul-Henning Kamp phk at
Sat Jan 14 20:10:41 CET 2012

In message <4F118990.7020702 at>, 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
		Not available for anybody but the fetching thread.
		We don't have the body yet, but can stream
		"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