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