[BUGFIX] Stop a curl request after its gzip step fails

[thc1006]

This patch stops a curl request whose gzip step failed, instead of reporting the failure to the handler and then sending the request anyway.

Session::SendRequest compresses the body, and on failure it dispatches CreateFailed, marks the session inactive, and then carries straight on to build the operation and send. There is no return. So the caller is told the request failed and the request goes out regardless.

What actually goes on the wire

The part I had not expected is that the body being sent is not the caller's data.

deflateInPlace() compresses into the caller's own buffer. It has to write into that buffer to find out whether the result will fit, so by the time it reports that it will not, the buffer has already been written. Its own comment says when that happens:

this will only occur for long incompressible streams, more than ~20 MB for the default deflate memLevel of 8, or when *max_len is too small and less than the length of the header plus one byte

The caller only resizes the body when the compression succeeded, so on failure the body keeps its original length and loses its contents. No Content-Encoding header is set on that path either. The peer receives bytes that are neither the payload nor a gzip stream, with nothing to say which it should expect.

I measured it on this branch before changing anything, for bodies of 1, 500 and 5000 bytes of high entropy data:

body	size afterwards	same size	same bytes
1	1	yes	no
500	500	yes	no
5000	5000	yes	no

Two other lines move with the return

Adding the return forces a decision about the rest of the block, so I would rather name what moved than leave a reviewer to work out why.

deflateEnd() used to run after the callback, on the way out of the compression branch. An early return has to call it on this path explicitly, and the useful place is before the handler rather than after: the handler is application code, and releasing the zlib stream first means there is nothing left to leak if it throws. zs.msg points into that stream, so the message is copied out before the stream goes.

is_session_active_ used to be set to false after the callback returned. If a handler starts a new request on the session from inside OnEvent, that store lands after the new request has already marked the session active, and clears the flag under it. Setting it before the handler runs removes that. Neither in-tree handler re-enters the session this way, so there is no case for it here. If you would rather have that as its own change, say so and I will pull it out.

About GzipIncompressibleData

That case changes here, and it is worth being explicit rather than quiet about it.

It required a response, on the reading that data which will not compress is simply sent uncompressed, and what it checked was that the body kept its original size. That assertion holds and the conclusion does not: the size is unchanged and the contents are not. So the behaviour it has been pinning is a request that goes out with a body the compression step overwrote.

It now requires CreateFailed and no request at the server. If you would rather incompressible data still be sent, that is the alternative below rather than a smaller version of this change.

About keeping the payload

Refusing to send is the narrow reading of "do not send after reporting a failure". The other reading is that incompressible data should still go out, uncompressed, which is what the old case describes and what a user with high entropy telemetry would want.

That needs the original bytes to survive the attempt, either by compressing into a separate buffer or by copying the body first. Both cost a copy on the compression path, and it changes what a user gets rather than repairing what the code already promises, so I have left it in #4360 rather than deciding it here. Say the word if you would prefer it and I will do that instead.

Tests

AFailedCompressionStopsTheRequest sends a one byte body with gzip enabled and requires CreateFailed, and then requires the server to have received nothing.

The failure is arranged rather than injected. deflateInPlace() is given the body's own size as its output budget, so a one byte body cannot hold a gzip header and the deflate reports Z_BUF_ERROR. There is no allocator hook and no timing involved. The case asserts that the failure was reached before it checks anything else, so a change that made such a body compressible would fail the case rather than quietly leave it testing nothing.

The whole curl_http_test suite passes, 29 of 29, with OTELCPP_WITH_OTLP_HTTP_COMPRESSION=ON, under gcc and under clang with OTELCPP_MAINTAINER_MODE=ON, and under ASan and TSan with no sanitizer reports. The case sits inside the file's existing ENABLE_OTLP_COMPRESSION_PREVIEW block with the two other gzip cases, so like them it exists only when compression is built in. The counts differ by build for that reason: bazel test //ext/test/http:curl_http_test registers and passes 26 cases, the CMake build with compression on registers 29 and skips none. I report what ran rather than only that the run was green, because a case that is not built cannot fail.

@lalitb noted on #4448 that this one can proceed independently of the transport design discussion. It does not change the structure of the curl client and does not pre-commit anything there.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.73%. Comparing base (1c2b007) to head (fbb9387).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4457      +/-   ##
==========================================
+ Coverage   82.67%   82.73%   +0.07%     
==========================================
  Files         516      516              
  Lines       20197    20200       +3     
==========================================
+ Hits        16696    16711      +15     
+ Misses       3501     3489      -12     

Files with missing lines	Coverage Δ
ext/src/http/client/curl/http_client_curl.cc	93.14% <100.00%> (+2.82%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.