Re: Pseudo Headers in Binary Representation of HTTP Messages (RFC 9292)

Hi Norman,


On Thu, Jul 6, 2023 at 4:03 PM Norman Maurer <norman_maurer@apple.com>
wrote:

> Hi all,
>
> I have a question related to pseudo headers and binary http.
>
> https://www.rfc-editor.org/rfc/rfc9292.html#section-3.6
>
> Here it says:
>
> ----
> For field names, byte values that are not permitted in an HTTP field name
> cause the message to be invalid; see Section 5.1 of [HTTP] for a definition
> of what is valid and Section 4 regarding the handling of invalid messages.
> 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.
> ----
>
> And later on:
> ----
> Other pseudo-fields that are defined by protocol extensions MAY be
> included; pseudo-fields cannot be included in trailers (see Section 8.1 of
> [HTTP/2]). A Field Line containing pseudo-fields MUST precede other Field
> Line values. A message that contains a pseudo-field after any other field
> is invalid; see Section 4.
> ----
>
> This is a bit confusing to me as if I follow the first paragraph it seems
> like it wouldnt be allowed to use β€œANY” pseudo-headers as β€œ:” is not a
> valid char in header names for HTTP.
>
>
I agree this text has the potential for confusion. It doesn't help that RFC
9292 uses the term "pseudo-field" when RFC 9113 uses consistently only
pseudo-header field

The intent of RFC 9292 seems to be to allow other pseudo-header fields in
the messages. One way to read this is that a psuedo-header field name !=
HTTP field name (see https://www.rfc-editor.org/rfc/rfc9113#section-8.3)
and therefore the rules can be bent a bit to allow the colon. However, this
seems a bit of a stretch. It might be clearer to state that a Field Line
can either represent an HTTP field or a pseudo-header field, and that only
the first byte of the Name field may contain a : character (ASCII 0x3a)
that identifies the type.

Cheers
Lucas

Received on Thursday, 6 July 2023 15:27:46 UTC