-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HttpLoggingInterceptor decompresses gzip response body but not request body #6982
Comments
That looks like gzipped content. Are you saying it's a bug that the interceptor didn't detect non-text content and omit it? |
@JakeWharton I was thinking that is a wrong gzip text because I was comparing it with online tools gzip the test like this. The missing thing is the logging http interceptor doesn't log the GZIP request body. |
Yep - that seems like a bug. Both request and response body are checked with bodyHasUnknownEncoding, which allows gzip to pass. But only the response is decompressed. |
Having looked at implementing this, which is reasonably simple, I realised this line "Compressed request body" comes from your own logging, not the interceptor. If you are blocked on this, you should just add the following before you log
The fix looks reasonably simple https://github.com/square/okhttp/pull/7013/files, and maybe we should add the gzip function to make this simpler. Not sure whether we want to land this... |
I used the answer mentioned here compress the request body but after adding this interceptor the logging interceptor didn't print the request body and the compressed text is so strange like this:
Original request body: {"data":{"lng":"-122.0840926","lat":"37.4219524"},"device_id":"XXXXX"}
Compressed request body: ���������������9
� �����ڈ�h.�\� �$�x���L�0��D��x��������=���ኤӤ��r�Z*w�{D�A��J�ՒNX?��r�Q������
The text was updated successfully, but these errors were encountered: