- From: Brian Pane <brianp@brianp.net>
- Date: Fri, 29 Jul 2011 00:11:20 -0700
- 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? Thanks, -Brian
Received on Friday, 29 July 2011 07:11:54 UTC