Re: HTTP/2: allow binary data in header field values

Hi Amos,

On Tue, Aug 29, 2017 at 05:28:23PM +1200, Amos Jeffries wrote:
> > 2. Binary header field values are prefixed with NUL byte (0x00), so
> > that binary value 0xFF is encoded as a header field value 0x00 0xFF.
> > This allows binary-aware peers to differentiate between binary headers
> > and VCHAR headers. In theory, this should also protect peers unaware
> > of this extension from ever accepting such headers, since RFC7540
> > requires that requests/responses with headers containing NUL byte
> > (0x00) MUST be treated as malformed and rejected, but I'm not sure if
> > that's really enforced.
> There is no need for this. With the SETTINGS value already negotiating the
> ability HPACK simply needs to decode the wire syntax into a binary 'string'
> header.

There's no *need* but a huge value : it saves gateways from having to check
for any forbidden character in the string at the moment it decides to pass
them, to know if they have to be encoded or not. Having the information
upfront provides a significant benefit.

> I am very doubtful that getting
> all this done before QUIC rolls out is going to be possible - a negotiable
> extension is far more realistic and will allow a testing rollout to happen
> before everybody in the HTTP world has to change code for it.

I tend to think that negociation is the only really safe way there as well.
We could possibly state that the knowledge of the other side's support can
be enforced by configuration, this would allow low-latency profiles in various
web services environments when both ends are well controlled.


Received on Tuesday, 29 August 2017 06:43:12 UTC