tree 3ca6ec72e3704ebe581d5288f2b54fe47fbb7cef
parent f30fd200f13e6099b81edbf1544701de25d65087
author diannahu <diannahu@google.com> 1683331253 -0700
committer Copybara-Service <copybara-worker@google.com> 1683331333 -0700

Support multiple interim responses in SimpleClient.

Currently, SimpleClient and descendants support 100 Continue responses (an
interim response) by reading in 100 Continue to response_headers(). Then once
100 Continue is populated and verified, the client calls
ClearPreliminaryResponse() so that response_headers() can be reused for the
final response.

This CL updates SimpleClient and descendants to support multiple interim
responses by introducing interim_headers(), an ordered sequence of BalsaHeaders
for interim responses. This CL removes ClearPreliminaryResponse() and adds
WaitForInterimResponse(), which in the future may be called multiple times.

SimpleHttpClient also calls BalsaFrame::set_use_interim_headers_callback(true),
which gives some additional testing confidence in this new code path.

This CL simplifies some 100-specific logic in the test clients. However, the
client continues to treat 101 as a final response (even in SimpleHttp2Client,
for consistency with SimpleHttpClient) due to the issue in cl/528583898.

One part of this CL involves updates to the QUIC (test) client ecosystem. I
decided to replace the interim/preliminary headers functionality in
QuicTestClient, as updating interim headers on querying (rather than on
receipt) can interact strangely with stream resets and timeouts. This CL
instead plumbs a callback to update interim headers with the flow
SimpleQuicClient --> GfeMockableQuicClient --> QuicSimpleClientSession -->
QuicSimpleClientStream, which can immediately update interim headers on
receipt. A comparison:

$ blaze test //gfe/gfe2/e2e:expect_100_continue_test_ietf_quic
Before: "PASSED in 307.2s" (http://sponge2/2c1eb63c-2bcc-4399-a329-98c638f562ba)
After: "PASSED in 11.0s" (http://sponge2/6c178f44-0aa3-4684-a4b0-e52fdbe61ae2)

I also verified with ++haoyuewang@ that the QuicSpdyClientStream changes do not
have a production impact on Hyperloop.

Huge inspiration from and thanks to ++bnc@'s foundational cl/379795244, which
has made this CL possible!

PiperOrigin-RevId: 529847861