On 2/03/2012 12:09 p.m., Zhu, Shan wrote:
Thanks Alex and Amos for your quick response.
Including the range request for cache key calculation sounds more generic than
hacking the range into the object file names. I am moving toward this
direction. However there may be an ambiguity problem.
Suppose we have Squid to be able to cache store the range, we may very likely
have the following two contents cached, for example, if we get multiple HTTP
requests with and without range requests.
1. A whole object file
2. A range of the object file
Now if we receive another HTTP request with the same range of the same object
file, we need to decide whether to respond with stored content 2 or to respond
with the range from stored content 1, as 1 contains 2.
I haven't found a good clue to solve this problem. Any idea?
When you consider (1) as being just another range (the whole length) and
treat it same as any partial, this problem disappears. The cached object
invalidation rules apply exactly as if the server had sent If-Range in
its Vary: header.
Your testing results should show:
If (1) is finished receiving first (2) should have been a HIT on that
and any late finishing (2) needs to be invalidated/dropped on completion.
If (2) arrived first, (1) needs to invalidate/drop that copy of (2).
If (1) and (2) are alternate variants on some other header (eg gzip
vs non-gzip), then a following fetch must match one or other regardless
of range before it can be used. Marking the whole as just another
variant on range makes this easy.
Amos
