RE: Range requests and content encoding

That's murky, because C-E is often used as if it were a transfer encoding.  Do most people request a range and "Accept-Encoding: gzip" expecting to get a partial gzip that may back-reference content that isn't in the transferred portion?  If you're actually patching up a truncated download, that's fine -- if you actually only need that part of the file, though....

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, December 21, 2015 6:29 PM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Range requests and content encoding

RFC 7233 does not mention content encoding at all.  Same for transfer encoding.  I assume that is because this is completely unspecified and therefore completely unreliable, however, for my sanity...

My reading is that a 206 response includes ranges of the encoded message, and that the content-encoding applies to the complete message body prior to being split into ranges.  Thus, if I had a "x2" content encoding that turned "Hello World!" into "HHeelllloo  WWoorrlldd!!", asking for bytes 3-5 would get you "eel" and not "llo".

The text in Section 4.1 suggests that you would not include a Content-Encoding header field if the client used If-Range on the expectation that they already know.  That seems pretty dangerous, but it's consistent with the idea that you are repairing a larger message.

On the other hand, I have to assume that a Transfer-Encoding applies
*after* the range request.

p.s., I've opened https://github.com/httpwg/http11bis/issues/11 for this.

Received on Tuesday, 22 December 2015 04:37:43 UTC