Re: Partial contenet,206

On 1/30/2013 8:48 AM, Amos Jeffries wrote:
> Does not matter. For starters we want to be *able* to store any
> cacheable response.
Since I dont know the exact progress of collapse forwarding.
The request contains the desire to fetch partial data so now the only
thing is to somehow store and re-serve it.
If I remember right the vary headers are being used to create the
store-id of the request.

What is actually being done when forcing full response rather then partial?

What I was pointing about the store-id being decided before getting any
data is for what i'm about to write.

What happens in a case when a user requests partial content and the
server denies it and returns full response? squid cache that or not?

A nice example for partial content that is distributed on multiple
objects is YOUTUBE and other videos.
One video can be composed from partial parts of one video.
There are situations which some client fastforward to specific place in
the video but still the player works with the chunks intelligently
enough that only some of the chunks are out of the fixed size of a chunk.
So eventually it's ok.

So we can might try to store partial responses in a cache object
specifically for partial response.
This is where my question was about size since most of the clients will
request more then just 8k chunk and we can even do some statistics from
existing live server logs to make sure of it.

This is the most practical way in the current situation.
This indeed will open a small weakness in cases which there are two
clients requesting the same object one with partial content request and
the other a full response.
A solution for that can be for squid to learn if it dosn't know how to
serve partial content from a complete file.

Is there any plans for collapse forwarding?
I couldn't see any written one in 3.3 or 3.4 .

-- 
Eliezer Croitoru