Re: if-range requests and compressed response

On 28/07/11 22:33, Ashok Kumar wrote:
> Hi All,
>
> Can someone clarify on which representation the "Range" points to for an
> "If-Range" request, when the original response was compressed.
>
>   * Should the server return the specified range from the compressed
> response (i.e. compress the original content again, if needed, and send
> the relevant range, assuming the compression algorithm generates the
> same byte stream again as the previous response!!) or

Critical assumption. Have you noticed how two installs of same 
compression software can produce different output for the same input?

It seems to me _de_compressing might be safer. Anyone wiser able to say 
for sure?

>   * does the range point to bytes from the (decompressed/)uncompressed
> response? if so, can the 206 partial response be non-compressed, though
> the original response was compressed. How will client "fill" its cache
> with this range? (i.e. will the client cache have a complete response
> after receiving this for the given E-Tag?)

Does that client have identical existing ETag value? AND identical 
timestamps on both versions?

RFC 2616:
"
    A cache MUST NOT combine a 206 response with other previously cached
    content if the ETag or Last-Modified headers do not match exactly,
"

>
> Also, If the Range points into compressed response, then I need a second
> clarification, when if-range has an E-tag and when it carries a
> date.When the If-Range carries an E-tag, we know if the original
> response was compressed or not. But with last modified date, how to
> determine if the original response was compressed or not?

see above.  BOTH ETag and Last-Modified must be identical for any 
merger. If either is missing or different no merge.


Someone will probably flame me about this, but ... IMO having a date in 
there means no Etag. So the cache can't use any version for which it has 
an ETag.

Following that implication, and combining it with:
   RFC 2616 section 10.2.7 206 Partial Content:
  "The response MUST include the following header fields: [...] ETag"

I conclude that no cache may legitimately respond to an If-Range 
containing a date.

Unless it were to synthesize an ETag for that reply. Which would then no 
longer match the requested object and thus erase the benefit of 
responding with 206 in the first place.

Or, would this be a valid 206 header value?
    ETag: ""


AYJ

Received on Thursday, 28 July 2011 11:15:31 UTC