zalando / logbook / #5144 / 1
100%
master: 100%

LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran
Files 208
Run time 6s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 100.0%. Remained the same
#5144.1

push

web-flow 
Issue 2103/malformed chunked response (#2145)

Handle cases when okhttp can't parse a malformed chunked body

Logbook wraps the original `okhttp3.Response` in `org.zalando.logbook.okhttp.RemoteResponse` in it's LogbookInterceptor. When a response body is requested, `org.zalando.logbook.okhttp.RemoteResponse` attempts to read the original response buffer stream and buffer it during a state transition from `Offering` to `Buffering`. When the response is chunked and the body is malformed, okhttp throws `ProtocolException` and closes the underlying stream. In the result, not only the response is not logged by Logbook, but the caller doesn't get access to the original response (with faulty body).

To address this I attempt to:
-  okio.BufferedSource.peek() method when buffering the response body, and when it fails to fallback to a string `"!This is not a real response body. Logbook was unable to read the response body!"`, that will appear in the Logbook's log as the response body. This is done to not omit logging the response completely and to avoid misleading the client that the body is empty.
- when LogbookInterceptor returns the response back from the intercept call, it calls `toResponse()` method, that will also trigger the buffering flow that would return the `"!This is not a real response body. Logbook was unable to read the response body!"` as body. To avoid this, as because the `peek` method was used on the BufferedSource, the BufferedSource wasn't closed, so returning the original `okhttp3.Response` should be safe in this case.

3716 of 3716 relevant lines covered (100.0%)

1.0 hits per line

Source Files on job #5144.1