New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 666936 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 3
Type: Bug



Sign in to add a comment

[Cronet] Cronet fails SDCH-encoded responses with Network error: net::ERR_CONTENT_DECODING_INIT_FAILED (-371)

Project Member Reported by mef@chromium.org, Nov 18 2016

Issue description

Cronet on iOS doesn't support SDCH encoding, but if app explicitly sets Accept-Encoding=sdch and gets response with Content-Encoding=sdch, then request fails with the following error:

[1117/162928:ERROR:crn_http_protocol_handler.mm(805)] HttpProtocolHandlerCore - Network error: net::ERR_CONTENT_DECODING_INIT_FAILED (-371)

For other unknown encoding types raw response data is passed through to the application, and it could make sense to do the same for SDCH.

I have more context for this if necessary.
 

Comment 1 by mef@chromium.org, Nov 18 2016

This CL fixes the reported issue: https://codereview.chromium.org/2512263002 and is consistent with current treatment of other encodings, but needs additional discussion for the future direction.
This is a bug. We should fail this case.
Cronet iOS should disallow adding accept encoding header.
There's some ambiguity in my last comment. Returning ERR_CONTENT_DECODING_INIT_FAILED is working as intended. Cronet should add handling to prevent API client from adding accept encoding header.

Comment 4 by mef@chromium.org, Nov 21 2016

Does it apply only to SDCH or to any custom accept-encoding? 

Currently Cronet allows to explicitly set Accept-Encoding header, and passes-through raw response data for encodings which it does not recognize, but errors out specifically for SDCH.

Should Cronet differ from Chrome in this regard to allow apps to use their own content decoders?
Apps and net embedders should not be able to use their own content decoders (as per our offline conversation).  We don't currently enforce that, but we should, and I'd like to move in the direction of enforcing it if possible.

Have you explored if the consumer can encapsulate their compression so we don't have to deal with these issues in Cronet?
  
a side note:

Cronet Android currently strips Content-Encodings. To be consistent, Cronet iOS could do something similar.

https://cs.chromium.org/chromium/src/components/cronet/android/java/src/org/chromium/net/impl/UrlRequestBuilderImpl.java?rcl=0&l=100
    @Override
    public UrlRequestBuilderImpl addHeader(String header, String value) {
        if (header == null) {
            throw new NullPointerException("Invalid header name.");
        }
        if (value == null) {
            throw new NullPointerException("Invalid header value.");
        }
        if (ACCEPT_ENCODING.equalsIgnoreCase(header)) {
            Log.w(TAG, "It's not necessary to set Accept-Encoding on requests - cronet will do"
                            + " this automatically for you, and setting it yourself has no "
                            + "effect. See  https://crbug.com/581399  for details.",
                    new Exception());
            return this;
        }
        mRequestHeaders.add(Pair.create(header, value));
        return this;
    }

Comment 7 by mge...@chromium.org, Nov 22 2016

Owner: mef@chromium.org
Status: Assigned (was: Untriaged)

Comment 9 by mef@chromium.org, Jan 3 2017

Status: Fixed (was: Assigned)

Sign in to add a comment