ons 2011-08-31 klockan 19:39 +1200 skrev Amos Jeffries:
> IIRC we decided against compacting ranges due to issues with Adobe
> reader products combined with a lack of clear RFC support to stand on.
What exactly do you refer to as "compacting ranges"?
There is many things that can happen with ranges in an proxy.
My preference is for
* On cache misses, relay the server response as-is. Do not try to
compose ranges from the incoming response, at least not by default.
* On cache hits, produce 206 responses from the cached response, in the
order requested by the client. This is something that can be improved a
lot in Squid as last I know we can only produce ranges in linear order.
When caching or partial responses gets implemented things gets more
complicated, but there is paths forward while still keeping sanity.
* If the request can be satisfied entirely from cache then produce a 206
response from what we have.
* If there is pieces missing AND the cached response have an ETag then
forward the request using If-Range and the requested ranges minus what
we already have in cache. Do not respond to the client until a
satisfying 206 response is seen from the server. Keep bandidth controls
limiting in both directions to the actual delivered speed, with suitable
tuning knobs.
* If the server response is not a 206 then relay it as-is.
* If the server response is a 206 but which do not satisfy the requested
ranges or ETag then fail with an error, or retry the request as a cache
miss, or perhaps relay the response as-is and hope the client & server
knows how to communicate. Also blacklist the server from partial
response caching.
* Do not cache partial responses unless there is an ETag.
Regards
Henrik
Received on Sat Sep 24 2011 - 14:17:44 MDT
This archive was generated by hypermail 2.2.0 : Sun Sep 25 2011 - 12:00:03 MDT