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.
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,