| commit | d907cd88312862f0577833c73c13e1b3bd51b090 | [log] [tgz] |
|---|---|---|
| author | diannahu <diannahu@google.com> | Fri May 05 17:00:53 2023 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri May 05 17:02:13 2023 -0700 |
| tree | 3ca6ec72e3704ebe581d5288f2b54fe47fbb7cef | |
| parent | f30fd200f13e6099b81edbf1544701de25d65087 [diff] |
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
QUICHE stands for QUIC, Http, Etc. It is Google‘s production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools. It powers Google’s servers, Chromium, Envoy, and other projects. It is actively developed and maintained.
There are two public QUICHE repositories. Either one may be used by embedders, as they are automatically kept in sync:
To embed QUICHE in your project, platform APIs need to be implemented and build files need to be created. Note that it is on the QUICHE team's roadmap to include default implementation for all platform APIs and to open-source build files. In the meanwhile, take a look at open source embedders like Chromium and Envoy to get started:
To contribute to QUICHE, follow instructions at CONTRIBUTING.md.
QUICHE is only supported on little-endian platforms.