zalando / logbook

100%

master: 100%

LAST BUILD ON BRANCH main

branch: SELECT

CHANGE BRANCH

x

• No branch selected
• 126fae36d496aa67b95b122a6e7db5543adfaf04
• 14407c8617bb09e74a2fc2b9006b706f0edfe80c
• 14e4fd98e99f644486f4cecde556b147dbc4c2c1
• 20031ecbe6c25f145338d2eff8b24a101a02d7f5
• 22830e6cb87f090645ad5724101e510463a41ab4
• 2e1a61f6125d9ef2ef066d38ad4b2b008d088f1c
• 30b16767be75c7e65feaff620993b58cec283e60
• 32dda0f8e7bcb138e0c2b3ce35153557e041d08e
• 4f4f1a6bced2d8564585edc5edfa16aac5c13933
• 5e73414eeb0a187dfde33c81c6efeb287b52bc89
• 6a4aa1884b768d510c20520076f468c9bce22aee
• 6b1168bbd922f02058344ab436c2d2230a0fd97d
• 6e7e233a0756d0062085a6b4799e944f8c4526c1
• 7001e0b623b03330c366b71fa146c493b6ac8bfb
• 73850d655f1514ade0ff8b2d2aa848288a1877a6
• 7d2d192841575f8164f72db400a22eb4c74aadc3
• 8093f809642650d888afbf9fec715772e1475d8c
• 88ffd85bd17a9a64f12879bd519faafa9826aa09
• 9650de4d1aeefdb65eb37996d5cfb4481a0a0d64
• a3ad8309fcf535c4766ec300b565dc7906dbeba1
• aeed1aa8d2f56b2cab80c97590fb1c1389ac6855
• b128e8690f0aebd12c364df779f526c30b242dc9
• b23cfe3fc9d905b2adef613f66b6418a605e64d8
• c4104541d3f10500ca788fa25c846304dc232f5f
• c54d0cb046651201499cebb952016222d89fd3d0
• ceab048dcab1df12456389fba04de4c8a663aedd
• d254b6ed2e1821e1177963549d623a6ffdbfcaf2
• d6fcfe02539f26df5fbf6f2da89ced41fc5c3408
• f57886ad8833fb89a8ad464d2eb148998b701145
• ffbd135aa37598724cb78ca584cac3cee0aa765d
• main
• master

Build # #5145

Build Type

push

Committed by web-flow

Commit Message

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.

Run Details

16 of 16 new or added lines in 2 files covered. (100.0%)

3716 of 3716 relevant lines covered (100.0%)

1.0 hits per line