incorrect handling of large HEADERS frame

[marten-seemann]

When the client exceeds the SETTINGS_MAX_FIELD_SECTION_SIZE, quiche closes the connection (!) with a H3_EXCESSIVE_LOAD error.

RFC 9114, Section 4.2.2 explains that the client might not have learned about the limit if the request goes through intermediaries, so exceeding the size is not necessarily a protocol violation.

If an implementation wishes to advise its peer of this limit, it can be conveyed as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it. However, an HTTP message can traverse one or more intermediaries before reaching the origin server; see Section 3.7 of HTTP. Because this limit is applied separately by each implementation that processes the message, messages below this limit are not guaranteed to be accepted.

Instead of closing the connection, quiche should probably just send a 431 status (and sending a STOP_SENDING for the stream). The RFC doesn't specify the reset error code, but I think both H3_EXCESSIVE_LOAD or H3_REQUEST_REJECTED would be appropriate.

[LPardue]

HTTP header size limits are really a best effort hint, especially given the nature of HTTP intermediation and version translation. In a proxy chain, you've already had to advertise the limit to the client before you might know you upstream limit anyway. e.g.

client <-> proxy 1 (field section limit X) <-> proxy 2 (field section limit Y)

Clients might not have any recourse to adjust the size of the message headers anyway. In such circumstances if a request fails, it fails always.

The default for this config is to enforce no limit; see https://docs.quic.tech/quiche/h3/struct.Config.html#method.set_max_field_section_size. A quiche based server that wants to implement the proposed approach can leave the config value unset and implement the size checking in the application layer when processing request headers. That achieves the same outcome but without the ability to advertise some limit in settings; not too disimilar to how HTTP/1.1 has to do things anyway (since there are no advertised limits there).

The quiche HTTP/3 module is not intended to deal with the HTTP semantic layer, so generating some response code would be out of scope for it. A possible feature request would be to allow the config to advertise a limit but disable the enforcing of it in quiche with H3_EXCESSIVE_LOAD.