Allow responses to HEAD requests to contain Content-Length or Transfer-Encoding The failing prober sends curl requests with the [`-I` param](http://cs///depot/google3/net/fabric/monitoring/cloud_sdn_management/cep_workflows/csdnm_efg_probers/efg_control_plane_shard0_prober/efg_control_plane_shard0_prober.pb.txt;ws=reubent%2F418520;l=63), meaning it is sending a `HEAD` request. Enforcement of `content_length_or_transfer_encoding_in_bodyless_response` was initially added to the same block where we check if the response should have a body or not. Responses to HEAD requests should not have a body. The logic error there is that, even though a response to a HEAD request cannot have a body, it is still permitted by the RFCs to return headers that describe the body it _would have_. RFC 9110, Section 9.3.2: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET". So this check has been moved to been moved to BalsaFrame::ProcessHeader and only limits TE/CL on 1xx and 204. New e2e and unit tests are added to confirm all RFC defined behavior: > A server MAY send a Content-Length header field in a response to a HEAD request (Section 9.3.2); `HEADResponseWithContentLengthAllowed` > A server MAY send a Content-Length header field in a 304 (Not Modified) response `304WithContentLengthAllowed` > A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content) `1xxResponseWithContentLengthDisallowed and 204ResponseWithContentLengthDisallowed` > Transfer-Encoding MAY be sent in a response to a HEAD request or in a 304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET request, neither of which includes a message body `304WithTransferEncodingAllowed` and `HEADResponseWithTransferEncodingAllowed` > A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content). `204WithTransferEncodingDisallowed` Protected by gfe2_reloadable_flag_use_zoll_balsa_http_validation_policy. PiperOrigin-RevId: 949125790
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.
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.
Usage: quic_packet_printer server|client <hex dump of packet>
Usage: crypto_message_printer_bin <hex of message>
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>
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
Most log messages in QUICHE use the QUICHE_DLOG macro. In standalone quiche, these all either go to stderr, or are suppressed, based on the --stderrthreshold flag.
To send INFO level log messages to a file, you would therefore invoke
<binary> <args> > <logfile> 2>&1
Use the --helpfull flag for more.