Re: if-range requests and compressed response

On Thu, Jul 28, 2011 at 3:33 AM, Ashok Kumar <ashokkumar.j@gmail.com> 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
>  * 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?)

I looked into this same question a while ago and concluded that the
right interpretation is your first one: "return the specified range
from the compressed response."

The key sections of RFC 2616 are 14.35.1:

"Byte range specifications in HTTP apply to the sequence of bytes in
the entity-body (not necessarily the same as the message-body)."

and 14.11:

"The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body."

Putting these two sections together, the server must interpret the
Range request relative to the entity-body, and the entity-body is the
document *after* compression and any other Content-Encodings have been
applied.

If I remember correctly, this interpretation is consistent with how
Apache and nginx do their response filtering: compression is applied
first, and then the requested byte-ranges are extracted.

As you noted, this implies that a server (or intermediary) that does
dynamic compression is implicitly required to produce the same output
every time it compresses the same response.  This means, for example,
that a server can't reuse its gzip dictionary state across multiple
responses on the same connection in hopes of achieving better
compression.  But the server shouldn't be doing that anyway, based on
the "considering messages in isolation" clarification in HTTPbis:
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/288

-Brian

Received on Thursday, 28 July 2011 16:24:04 UTC