Chucker misses headers for compressed responses

[vbuberen]

✍️ Describe the bug

When I tried to reproduce the #472 issue found out that check isGzipped in ChuckerInterceptor always returns false for responses in Chucker sample app for gzip request. As it turned out headers in Response object contained no Content-Encoding header. After looking further I found out that OkHttp removes Content-Encoding and Content-Length headers from compressed responses. Due to this fact all responses were treated as non gzipped by Chucker and Chuck all this time.

💣 Steps to reproduce

1. Open Chucker sample app.
2. Do http activity.
3. Open /gzip transaction and see no Content-Encoding and Content-Length headers, while they should be there https://httpbin.org/#/Response_formats/get_gzip

🔧 Expected behavior

I believe that Chucker should show raw data when it comes to headers, not some redacted version.

📷 Screenshots

📱 Tech info

• Chucker version: 3.3.0 and down to the original Chuck library

📄 Additional context

To get so-called raw data from responses Chucker should use not response, but networkResponse object https://square.github.io/okhttp/4.x/okhttp/okhttp3/-response/network-response/ , since such object contains all headers (see attached screenshot).
This fix should not only go into develop branch for the future 4.x release, but also to 3.x branch for future 3.3.1 release for users, who still need to support APIs down to 16.

[MiSikora]

I'm not sure I agree with that it is redacted data. It feels quite natural to me. If I'm interested in a networkResponse I apply ChuckerInterceptor as a networkInterceptor. I gave my feedback about this in an issue about a similar thing - #331 (comment).

I don't mind going either way but I wouldn't consider it a bug.

[vbuberen]

Right, missed that. Actually, have never used as networkInterceptor in real life project as far as I remember.
Checked - seems to work fine.