Repository navigation
Ranges and Content and Transfer Encoding #11
Description
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.
Activity
enygren commentedon Apr 6, 2016
This is also potentially weird in the case where a client specifies multiple Accept-Encodings and a Range request, such as "Accept-Encoding: gzip, br". In these cases, the bytes returned will depend on which Content-Encoding is selected by the server. (As minimal operational guidance, clients presumably will need to be very careful about this and may need to limit which encodings they accept for subsequent ranges requests based on what was returned from the first, or be prepared to get the full object back.)
mnot commentedon Apr 11, 2016
RFC7233 Section 3.1 says:
RFC7231 Section 3.1.2.2 says:
That gives you all the information you should need. Could it be clearer? Probably. A hyperlink to defining terms would probably help.
[-]RFC 7233: Content and Transfer Encoding[/-][+]Ranges and Content and Transfer Encoding[/+]Refactor the range specifier grammar to simplify and reduce distincti…
reschke commentedon Jan 7, 2020
I believe this issue can be closed.
(editorial) Explicitly reference representation data in Range and 206…