Draft: draft-ietf-quic-http

Commentary: Three of these are simple -- origin and asterisk form lives in Semantics now , and we did n't get an update to the new pointer . Those are in the first commit . The second commit might be more controversial . See . 
 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 do n't , so I think it covers it . 
 said 
 said 
 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 in , the core HTTP spec now has , written more clearly . We should just reference them . 
 That WFM . Barry 
 now includes the same text as 
 Great ; sounds like I 'll be moving to a Yes ballot when I see the revised draft posted . Thanks ,  , and all . Barry 
 points out that , in addition to a couple easily - resolved normative references to the  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 . 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 . "
Paragraph (version A):
The "chunked" transfer encoding defined in Section 7.1 of HTTP11 MUST
NOT be used.
Paragraph (version B):
Transfer codings (see Section 6.1 of HTTP11) are not defined for
HTTP/3; the Transfer-Encoding header field MUST NOT be used.
Paragraph (version A):
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.
Paragraph (version B):
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).
Paragraph (version A):
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
origin or asterisk form; see Section 3.2 of HTTP11.  Clients that
generate HTTP/3 requests directly SHOULD use the ":authority"
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
the ":authority" pseudo-header field.
Paragraph (version B):
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
origin or asterisk form; see Section 7.1 of SEMANTICS.  Clients
that generate HTTP/3 requests directly SHOULD use the ":authority"
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
the ":authority" pseudo-header field.
Paragraph (version A):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
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
with a value of '*'; see Section 3.2.4 of HTTP11.
Paragraph (version B):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
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
with a value of '*'; see Section 7.1 of SEMANTICS.