Change:
Three of these are simple -- origin and asterisk form lives in Semantics now, and we didn't get an update to the new pointer. Those are in the first commit. The second commit might be more controversial. See .
NAME just a heads-up that this is aligning with http2-bis in referencing SEMANTICS, which says... I'm not totally thrilled with dropping that back to a SHOULD, but it has the caveat that requests will look malformed if you don't, so I think it covers it.
NAME said
NAME said
NAME This is text imported mostly-unchanged from RFC7540, but I'm always happy to improve upon the past. This point actually in the discussion of , which is rewording that paragraph slightly, but your point would still remain with the new text. The key is that HTTP fields are an extension point, and some fields are defined to have hop-by-hop semantics. The endpoint necessarily knows the meaning of all fields it generates, and so we can tell it that it MUST NOT generate a field with hop-by-hop semantics. However, the intermediary does not necessarily know the meaning of all fields some other endpoint sends through it. Another way to read this is "MUST remove all fields which are known to have hop-by-hop semantics, but we acknowledge you might miss some"; that's a difficult requirement to test. We've tended to use SHOULD for unenforceable MUSTs throughout these documents. If you'd like to suggest a better way to phrase it, I'm open to incorporating it into or a follow-up.
As NAME in URL, the core HTTP spec now has , written more clearly. We should just reference them.
That WFM. Barry
now includes the same text as URL
Great; sounds like I'll be moving to a Yes ballot when I see the revised draft posted. Thanks, Mike, and all. Barry
NAME points out that, in addition to a couple easily-resolved normative references to the HTTP/1.1 draft (this content has moved to Semantics), there's a normative reference to "chunked" transfer encoding being prohibited. But technically, this is still a MUST NOT for an informative reference. One resolution would be to make it a statement of fact rather than a conformance requirement -- to say that the transfer codings defined by the HTTP/1.1 are HTTP/1.1-specific and not applicable to HTTP/3. But that's a broader assertion than just "chunked." Is there a reason we need to keep e.g. "Transfer-Encoding: gzip"?
My +1 goes to talking about transfer-encodings in general rather than just chunked, but as stated in the review comment, IIUC we already use different language for endpoints and intermediaries and therefore am afraid we have to keep doing so.
I think that the tweak to translation behaviour is probably necessary. I'll be opening a bug on h2 as well.NAME Thank you for your comments and the changes. I agree about the intent, and I am fine with retaining the SHOULD that we already have. I also like the updated text in the other section that explicitly states that intermediaries "MUST decode and remove transfer encodings."

Discussion:
the message exchange, they must be received and processed before the message can be consumed.  See header-formatting for more details. <del> The "chunked" transfer encoding defined in Section 7.1 of HTTP11 MUST NOT be used. </del> <ins> Transfer codings (see Section 6.1 of HTTP11) are not defined for HTTP/3; the Transfer-Encoding header field MUST NOT be used. </ins> A response MAY consist of multiple messages when and only when one or more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a

present in an HTTP/3 request header; when it is, it MUST NOT contain any value other than "trailers". <del> This means that an intermediary transforming an HTTP/1.x message to HTTP/3 will need to remove any fields nominated by the Connection field, along with the Connection field itself.  Such intermediaries SHOULD also remove other connection-specific fields, such as Keep- Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they are not nominated by the Connection field. </del> <ins> An intermediary transforming an HTTP/1.x message to HTTP/3 MUST remove connection-specific header fields as discussed in Section 7.6.1 of SEMANTICS, or their messages will be treated by other HTTP/3 endpoints as malformed (malformed). </ins> 4.1.1.1.

To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in <del> origin or asterisk form; see Section 3.2 of HTTP11.  Clients that generate HTTP/3 requests directly SHOULD use the ":authority" </del> <ins> origin or asterisk form; see Section 7.1 of SEMANTICS.  Clients that generate HTTP/3 requests directly SHOULD use the ":authority" </ins> pseudo-header field instead of the Host field.  An intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a Host field if one is not present in a request by copying the value of

MUST include a value of '/'.  The exception to this rule is an OPTIONS request for an "http" or "https" URI that does not include a path component; these MUST include a ":path" pseudo-header field <del> with a value of '*'; see Section 3.2.4 of HTTP11. </del> <ins> with a value of '*'; see Section 7.1 of SEMANTICS. </ins> All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT

The ":authority" pseudo-header field contains the host and port to connect to (equivalent to the authority-form of the request-target <del> of CONNECT requests; see Section 3.2.3 of HTTP11) </del> <ins> of CONNECT requests; see Section 7.1 of SEMANTICS) </ins> The request stream remains open at the end of the request to carry the data to be transferred.  A CONNECT request that does not conform