W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: if-range requests and compressed response

From: Brian Pane <brianp@brianp.net>
Date: Fri, 29 Jul 2011 00:11:20 -0700
Message-ID: <CAAbTgTvXshh-Rev9OJF1kBMKx1TzBfnJ3kOyaeE1nciidBGsqA@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Thu, Jul 28, 2011 at 10:45 PM, Ashok Kumar <ashokkumar.j@gmail.com> wrote:

> So this also implies that for dynamically generated gzip compressed response, when server
> receives an If-Range, then server can only respond with 200 with uncompressed response?

I think there are two situations where the server could respond with a 206:

1. The If-Range request specifies an entity-tag, and the server knows
(via implementation-specific means) that this entity-tag is the same
as the ETag the server would use for the response at the present time.

2. The If-Range request specifies an HTTP-date, and the server knows
(via implementation-specific means) that the Last-Modified date it
would use for the response at the present time is no later than the
specified HTTP-date.

> This begs another question. Though not specific to HTTP WG, but just to make sure my
> understanding is correct. IIRC, Apache mod_gzip fixed the E-Tag generation problem
> by appending "-gzip" or similar to end of E-tag of the original content. If two runs of
> gzip compression don't produce the same output, isn't the E-Tag generated wrong?

If it's a weak ETag, then it's okay to use the same ETag value even if
two applications of compression yield outputs that aren't bytewise
equal.  If it's a strong ETag, like you'd need in order to support
If-None-Match or If-Range, then yes, the generated ETag would be wrong
in this situation; however... what's the use case in which two runs of
gzip, both starting with freshly initialized state (as is the case
when gzip is invoked dynamically on a per-response basis in every
server and proxy implementation I've seen), will produce different
output from the same input?  I can only think of a couple of ways to
cause the output to differ while still producing a response the client
can uncompress:
- Change gzip's compression level between the two runs, or
- Swap in a different compression implementation (that produces
different but still valid gzip-formatted output) between the two runs.
Neither of those is impossible, but I don't imagine that they're
common cases either.  Am I missing any other use case?

Received on Friday, 29 July 2011 07:11:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC