Permitted characters in HTTP/2 fields

At our last interim, we discussed potential ways in which HTTP/2 was probably too strict about characters (octets really) in field names and values.

The conclusion then was to loosen the restriction and mandate only a small set of checks.  This should match what implementations already do.

https://github.com/httpwg/http2-spec/pull/846 proposes the following rules:

Field names and values can't contain CR, LF, or NUL.
Field names and values can't start or end with SP or HTAB.
Field names can't include uppercase ASCII (A-Z) or COLON (with an exemption for pseudo-headers).

This loosens the previous rule that made a message malformed if the field value was not valid according to the core ABNF definitions.  With the change, messages are only malformed if the processing rules of a field explicitly say that the message is malformed.

This differs in one way from what was recorded from our previous discussion: colons.  I realized that the main reason for the rules was to avoid things like request smuggling attacks, for which missing colons could be problematic.  Most of these rules exist to avoid conversions from HTTP/2 to HTTP/1.1 resulting in smuggling, so it makes sense to be a little more comprehensive in the approach.

The idea here is that this makes intermediary responsibilities clear: the above checks are mandatory because they have direct security and interoperability consequences, but that is all that HTTP/2 requires of implementations.  Beyond that, the core rules of HTTP apply.

Received on Tuesday, 27 April 2021 05:55:38 UTC