Re: if-range requests and compressed response

Hi Ashok, everyone,

I think the answer to your last question is to look the Content-Encoding
header (I'm unclear on how ETag would indicate compression?), which
indicates whether the server has compressed the content to be sent.

As to the range question, I'm not sure compressing the content and using
range headers is compatible in any readily sensible manner. If suppose if
the server stores a copy of the compressed content, so it's guaranteed to be
feeding the same data every time (I have just tried gzipping two copies of a
file and got different results ­ possibly a timestamp included?), that could
work, in which case the range headers would indicate a place in the
compressed stream.

Ross

From:  Ashok Kumar <ashokkumar.j@gmail.com>
Date:  Thu, 28 Jul 2011 16:03:42 +0530
To:  "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Subject:  if-range requests and compressed response
Resent-From:  <ietf-http-wg@w3.org>
Resent-Date:  Thu, 28 Jul 2011 10:34:25 +0000

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
 * 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?)

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?


Thanks in advance,
Ashok

Received on Thursday, 28 July 2011 10:55:02 UTC