[quicwg/base-drafts] HTTP/3 Pseudoheader constraints are incorrect? (#2966)

[martinduke <[e-mail]>]

I'm carefully parsing the wording in quic-http sec. 4.1.1 and don't think it's right:

> Endpoints MUST NOT
>    generate pseudo-header fields other than those defined in [HTTP2].
>    The restrictions on the use of pseudo-header fields in
>    Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.

In RFC 7540, 8.1.2.1 says

> Endpoints MUST NOT
>    generate pseudo-header fields other than those defined in this
>    document...
> 
> Pseudo-header fields defined for requests MUST NOT appear
>    in responses; pseudo-header fields defined for responses MUST NOT
>    appear in requests.  Pseudo-header fields MUST NOT appear in
>    trailers.  Endpoints MUST treat a request or response that contains
>    undefined or invalid pseudo-header fields as malformed
>    (Section 8.1.2.6).
> 
>    All pseudo-header fields MUST appear in the header block before
>    regular header fields.  Any request or response that contains a
>    pseudo-header field that appears in a header block after a regular
>    header field MUST be treated as malformed (Section 8.1.2.6).

This notably does NOT include the further restrictions in 8.1.2.3:

> All HTTP/2 requests MUST include exactly one valid value for the
>    ":method", ":scheme", and ":path" pseudo-header fields, unless it is
>    a CONNECT request (Section 8.3).  An HTTP request that omits
>    mandatory pseudo-header fields is malformed (Section 8.1.2.6).

I am far from an expert on HTTP headers, but I suspect it's not right that clients could send quantities of :method, :scheme, and :path other than 1.

We should probably fix the section reference, though I haven't reviewed 8.1.2 carefully enough to know exactly how that should read.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2966