Re: Binary HTTP [RFC 9292] header name behavior

Hi Ricky,

It looks like you found a hole.  The intent was always to follow the tighter rules in HTTP/2 for name and value construction.  But I seem to have managed to point to only the value construction part.

An erratum is almost the right way to address this, but you might equally say that we flubbed it and need to revise the document to fix the problem.  In practice, implementations are generally downcasing, so an update - however that happens - to require that wouldn't be disruptive.

On Tue, Aug 12, 2025, at 03:58, Ricky Perez wrote:
> Hello,
> We are trying to define our Binary HTTP header name parsing behavior 
> and we were wondering what should be done when dealing with mixed HTTP 
> versions between OHTTP Client and Gateway. For context, RFC 9292 
> section 3.6-4 <https://www.rfc-editor.org/rfc/rfc9292#section-3.6-4> 
> mentions the following: 
> *"A recipient MUST treat a message that contains field values that 
> would cause an HTTP/2 message to be malformed according to Section 
> 8.2.1 of [HTTP/2] as invalid; see Section 4.".*
> This is clear for field values, but it does not mention field names. 
> Here is the scenario where we would like more clarity:
>
> An OHTTP Client having a connection to an OHTTP Relay using HTTP/1.1, 
> the Relay having a connection to the OHTTP Gateway using HTTP/2 and the 
> Gateway having a connection to the Target using HTTP/2. From a client 
> perspective, it is sending an HTTP/1.1 request, encoding it in Binary 
> HTTP using mixed-case header field names, but then the Gateway decodes 
> it and from its perspective everything is HTTP/2, meaning that 
> mixed-case header names should not be allowed.
>
> Should the Binary HTTP decoder treat it as an invalid message or should 
> it implicitly convert header names to lower-case?
>
> Thanks!
> Ricardo

Received on Monday, 11 August 2025 23:51:00 UTC