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

I agree with Sean here.. The second way is easier to understand imho.

Bye
Norman


> On 6. Jul 2023, at 17:35, Sean McArthur <sean@seanmonstar.com> wrote:
> 
> I find the second way you wrote it clearer, Lucas. In hyper, we forbid colons in generic header names, and treat pseudo-fields specially.
> 
> On Thu, Jul 6, 2023, 11:28 AM Lucas Pardue <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>> wrote:
>> Hi Norman,
>> 
>> 
>> On Thu, Jul 6, 2023 at 4:03 PM Norman Maurer <norman_maurer@apple.com <mailto: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
>>