how cronet gzip receive data?

[kbing x]

I found that,  if I understood incorrectly, please correct me

okhttp:

interceptor --> BridgeInterceptor --> netInterceptor --> CallServer

                        decompress data   

interceptor <-- BridgeInterceptor <-- netInterceptor <-- CallServer

              

cronet:

I received response header contain  "content-encoding -> gzip"

but when I checked byte buffer , bytes were decompressed 

Is there a way to disable gzip data in cronet?

[Dan Stahr]

Hi,

TL;DR: Leave Accept-Encoding and Content-Encoding handling to Cronet unless you have a very strong reason not to do so. Expect breakages if you don't.

Detailed answer:

To answer your question directly, no, there's no easy way to prevent Cronet from adding gzip as an accepted encoding and decoding gzipped response bodies.

On the way out, Cronet takes full ownership of the Accept-Encoding header and prohibits users from customizing the headers. The reason is covered in https://crbug.com/581399. The way to set the headers implicitly is to enable a particular encoding on the Cronet engine (e.g. enableBrotli()), which also sets up the decompression path. Users of Cronet should always receive the decoded stream and shouldn't worry about transport level compression or encoding. Gzip in Cronet is a non-configurable option, enabled by default.

As a result of the above, Cronet doesn't expect encodings it doesn't know about in the response (or that are disabled), so the below behavior isn't part of the public Cronet contract. Anyway, here's what happens with an ill-behaved server sending undesired data.

 - if Cronet sees an encoding it doesn't know how to handle at all (e.g. "my-custom-encoding") it doesn't attempt to decode the stream and simply passes it along.

 - if Cronet sees an encoding it knows how to handle and support for it is enabled, it decodes the stream. Notably, it doesn't strip the headers - Content-Encoding and Content-Length, if set, will refer to the encoded stream (see the bug above for more details).

 - if Cronet sees an encoding it knows how to handle and support for it is disabled, Cronet fails with a Content Decoding Failed error.

Hope this helps, please feel free to follow up with further questions.

Dan

[kbing x]

thank you Dan, 

 

currently , I have a problem that, 

I make a request in okhttp's Interceptor,  

original okhttp request:  

               response header has key-value "content-encoding -> gzip", 

               I can get byte buffer data in networkinterceptor, data bytes are gzip format

              some custom  logic depend on gzip data

cronet request in okhttpinterceptor:

               I get cronet response data has been decompressed,   

             so if I want to use gzip format data, should I  gzip it again(may be this is not a good solution)   :)

[Dan Stahr]

Looks like this question is related to the OkHttp transport library (https://github.com/google/cronet-transport-for-okhttp), can you open an issue there? If possible, please add details about the kind of business logic you need support for.