Google Git
Sign in
quiche / quiche / a1a1a9ed5c965ee914ae8437e8c56771ef4b0d6d
commita1a1a9ed5c965ee914ae8437e8c56771ef4b0d6d[log] [tgz]
authorQUICHE team <quiche-dev@google.com>Tue Nov 25 09:24:30 2025 -0800
committerCopybara-Service <copybara-worker@google.com>Tue Nov 25 09:25:27 2025 -0800
tree036040000ccacbfce17c9490732935affed99a5c
parent2a0d3a18389f8ac04b6d4a3586555c0e14231dd6 [diff]
Always reset content length status when removing the Content-Length header in BalsaHeaders.

Currently, when removing the "Content-Length" header, BalsaHeaders does not reset its internal content length status if "Transfer-Encoding: chunked" is also present. This can lead to inconsistencies where `content_length_valid()` remains true even after the "Content-Length" header is gone. This change introduces a new reloadable flag, `gfe2_reloadable_flag_reset_content_length_status_when_removing_content_length_header`, which, when true, ensures that the content length status is always reset when "Content-Length" is removed, regardless of the presence of "Transfer-Encoding: chunked". Tests are added to cover a scenario where both headers are initially present in a request.

I manually e2e tested, and confirmed that
* When gfe2_reloadable_flag_reset_content_length_status_when_removing_content_length_header is false, we saw `REQUIRED_BODY_BUT_NO_CONTENT_LENGTH` in the test backend http://screen/C7QyLfJxaEwCtsA.
* When the feature flag is true, the response code is 200, and the request headers sent by GFE has `transfer-encoding`: http://screen/9yDWwpGSFhnYVZi

I am now writing the nice automated e2e test that requires changes in the implementation. Given the tight timeline of the product launch, I don't think the automated test is blocking this change.

Protected by gfe2_reloadable_flag_reset_content_length_status_when_removing_content_length_header.

PiperOrigin-RevId: 836699619
3 files changed
tree: 036040000ccacbfce17c9490732935affed99a5c
  1. build/
  2. depstool/
  3. quiche/
  4. .bazelrc
  5. .bazelversion
  6. BUILD.bazel
  7. CONTRIBUTING.md
  8. LICENSE
  9. MODULE.bazel
  10. MODULE.bazel.lock
  11. README.md
  12. WHITESPACE
README.md

QUICHE

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.

Build and run standalone QUICHE

QUICHE has binaries that can run on Linux platforms.

Follow the instructions to install Bazel.

sudo apt install libicu-dev clang lld
cd <directory that will be the root of your quiche implmentation>
git clone https://github.com/google/quiche.git
cd quiche
CC=clang bazel build -c opt //...
./bazel-bin/quiche/<target_name> <arguments>

There are several targets that can be built and then run. Full usage instructions are available using the --helpfull flag on any binary.

  • quic_packet_printer: from a provided packet, parses and prints out the contents that are accessible without decryption.

Usage: quic_packet_printer server|client <hex dump of packet>

  • crypto_message_printer: dumps the contents of a QUIC crypto handshake message in a human readable format.

Usage: crypto_message_printer_bin <hex of message>

  • quic_client: connects to a host using QUIC and HTTP/3, sends a request to the provided URL, and displays the response.

Usage: quic_client <URL>

  • quic_server: listens forever on --port (default 6121) until halted via ctrl-c.

  • masque_client: tunnels to a URL via an identified proxy (See RFC 9298).

Usage: masque_client [options] <proxy-url> <urls>

  • masque_server: a MASQUE tunnel proxy that defaults to port 9661.

Usage: masque_server

  • web_transport_test_server: a server that clients can connect to via WebTransport.

  • moqt_relay: a relay for the Media Over QUIC transport for publishers and subscribers can connect to.

Usage: moqt_relay