• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

zalando / logbook / #5145
100%
master: 100%

Build:
Build:
LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran 02 Sep 2025 06:10AM UTC
Jobs 1
Files 208
Run time 1min
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

01 Sep 2025 01:14PM UTC coverage: 100.0%. Remained the same
#5145

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.

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

Jobs
ID Job ID Ran Files Coverage
1 #5145.1 02 Sep 2025 06:10AM UTC 208
100.0
Source Files on build #5145
  • Tree
  • List 208
  • Changed 2
  • Source Changed 2
  • Coverage Changed 2
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • 7e670690 on github
  • Prev Build on main
  • Next Build on main
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc