Re: [quicwg/base-drafts] Clarify and split the "malformed" definition (#3352)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -410,10 +417,10 @@ considered invalid.
 
 An HTTP request/response exchange fully consumes a bidirectional QUIC stream.

After reading the whole section, I think that while the section intends to talk about both push and requests, this paragraph is specific to requests.  I've added more discussion of push streams above, but I think I'm going to leave this particular paragraph alone, modulo fixing @LPardue's initial suggestion.

> -those defined in {{!HTTP2}}.  The restrictions on the use of pseudo-header
-fields in Section 8.1.2 of {{!HTTP2}} also apply to HTTP/3.  Messages which
-are considered malformed under these restrictions are handled as described in
-{{malformed}}.
+the status code for the response.
+
+Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate
+pseudo-header fields other than those defined in this document, except as
+negotiated via an extension; see {{extensions}}.
+
+Pseudo-header fields are only valid in the context in which they are defined.
+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 ({{malformed}}).

Nope, it actually does wrap this way by sheer coincidence.  (Or @martinthomson was playing a really long prank in RFC 7540.)

-- 
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/pull/3352#discussion_r368075798