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
