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.
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.