tor 2012-03-01 klockan 18:09 -0500 skrev Zhu, Shan: > 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?
To handle that you need to implement proper range caching. Which isn't really a very complex thing. 1. Cache the range response as you would cache any positive response. 2. On cache hit you need to forward a range request to fill in the missing pieces if the current request can not be entirely served from cache, and merge the two responses. You also need to delay responding until you know the new response is compatible. So it's in many senses very similar to cache validation. The most tricky part is probably the half-range-awareness of the store layer introduced in squid-3. Regards Henrik