(In reply to Masatoshi Kimura [:emk] from comment #3) > Firefox requests `gzip` Content-Encoding (via `Accept-Encoding` request header) while Chrome uses `identity` encoding. Chrome is right according to the spec. > https://fetch.spec.whatwg.org/#http-network-or-cache-fetch (Step 8.19.) > > If httpRequest’s header list contains `Range`, then append (`Accept-Encoding`, `identity`) to httpRequest’s header list. > > [Note] This avoids a failure when handling content codings with a part of an encoded response. > > Additionally, many servers mistakenly ignore `Range` headers if a non-identity encoding is accepted. > > Apparently we fail to handle the case where `XHR` or `fetch` adds a `Range` request header. I see that we are sending identity value along with gzip. I see that in case of range header, we do append the [identity](https://searchfox.org/mozilla-central/rev/bf8c7a7d47debb1c22b51a72184d5c703ae57588/netwerk/protocol/http/nsHttpChannel.cpp#823) value. The spec mentions to "append" the value into the header list and hence I think we are behaving as per the spec? We will discuss this internally during our bug review meeting to decide on further course of action. Fix should be straightforward. We need to just set the header instead of merge. However, I see that Chrome and Safari both just send `identity` for `Accept-Encoding` request header.
Bug 1874840 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Masatoshi Kimura [:emk] from comment #3) > Firefox requests `gzip` Content-Encoding (via `Accept-Encoding` request header) while Chrome uses `identity` encoding. Chrome is right according to the spec. > https://fetch.spec.whatwg.org/#http-network-or-cache-fetch (Step 8.19.) > > If httpRequest’s header list contains `Range`, then append (`Accept-Encoding`, `identity`) to httpRequest’s header list. > > [Note] This avoids a failure when handling content codings with a part of an encoded response. > > Additionally, many servers mistakenly ignore `Range` headers if a non-identity encoding is accepted. > > Apparently we fail to handle the case where `XHR` or `fetch` adds a `Range` request header. I see that we are sending identity value along with gzip. I see that in case of range header, we do append the [identity](https://searchfox.org/mozilla-central/rev/bf8c7a7d47debb1c22b51a72184d5c703ae57588/netwerk/protocol/http/nsHttpChannel.cpp#823) value. The spec mentions to "append" the value into the header list and hence I think we are behaving as per the spec? We will discuss this internally during our bug review meeting to decide on further course of action. Fix should be straightforward. We need to just set the header instead of merge. However, I see that Chrome and Safari both just sends `identity` for `Accept-Encoding` request header.