jiebi/CodeConvo huggingface dataset:
Code change:
though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.

Related discussion:
text: unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.
Code change:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Related discussion:
text: One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (methods) and a few request-modifying <del> header fields.  If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in safe.methods, the method semantics take precedence. </del> <ins> header fields.  A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request.  For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see safe.methods). </ins> HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and
Code change:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Related discussion:
text: is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> Responses (both </del> <ins> All responses, regardless of the status code (including </ins> <del> and </del> <ins> responses) can be sent at any time after a request is received, even if the request is not yet complete.  A response can complete before its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins> <del> ) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del> <ins> A client that receives a response while the associated request is still being sent SHOULD continue sending that request, unless it receives an explicit indication to the contrary (see, e.g., persistent.failures and RFC7540). </ins> 7.6.
Code change:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Related discussion:
text: 8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and
Code change:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Related discussion:
text: unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.
Code change:
... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.

Related discussion:
text: 8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and
Code change:
... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.

Related discussion:
text: unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.
Code change:
implies a requirement: I would have said instead that HTTP itself doesn't care whether content adheres to this stricture, though some implementations could (or MAY) normalize line endings before sending or after receiving content that uses a media type.
Maybe we can improve the spec by just killing the whole subsection? It refers to the canonical form in MIME, then say we don't neef that, and then makes recommendations for text/* that AFAIU everbody ignores.
This was a huge deal back in 1995-96 and was necessary to bless deployed practice of sending native line endings and expecting the user agents to process them. I guess we can ignore that now? Don't be surprised if JK brings this up in IESG last call.Not seeing anything here worth saving.

Related discussion:
text: 8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and
Code change:
Note that if we say it has serious security hazards and we don't mention that in Security Considerations, someone might complain.
PTAL
The text says I'd want to add: "Implementations must be careful about accurately parsing large values or rejecting the messages, as failure to accurately represent the advertised value due to overflows or loss of precision may have serious security consequences." I think it is important to remind, because implementations seem to have progressively shifted towards 64 bit repressentations since 7230, 32-bit ones are still much present, and the risk of desynchronization by advertising more than 4GB is high. By the way, some languages do no provide more than 52 bits of accuracy because they use floats to represent any number... The risk remains low (1 injected byte every 4 PB) but its worth asking to be careful.
Tweaked proposal:
WFM, but I'm still a bit concerned by the fact that we don't say what the receiver should do here, and it doesn't decide to receive too large a chunk :-/ Should we explicitly mention "a recipient must reject the message as invalid if it cannot accurately represent a received chunk size ?"
I think if we say something about that, we should align it with the language for Content-Length:
OK, but then conversion overflows is not the only issue (storing in a float or double is a huge problem, and nowadays sometimes developers don't know, they store it into a "number"). Probably that we should use the same wording for both and slightly adjust the end to say . We can hardly do more but this needs to be said. Using a float with 24-bit mantissa to represent a content-length is already a problem, but in a chunk, 48 MB are enough to miss 3 bytes and desynchronize on a final chunk!

Related discussion:
text: A recipient MUST be able to parse and decode the chunked transfer coding. <del> Note that HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response. </del> <ins> HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response.  Additionally, very large chunk sizes may cause overflows or loss of precision if their values are not represented accurately in a receiving implementation.  Therefore, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer representation. </ins> The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error.
Code change:
It isn't a normative change because the ABNF already requires port to be present in this form of request. The description is just inconsistent. I also intend to change the reference to 3986 to the right section of this document.
The as used for CONNECT describes the request target as comprising an authority, which consists of an IP or reg-name and, optionally, a port number. The example shows an explicit port of 80. What happens if an explicit port is not included? Does the proxy use the port number associated with the implied protocol (80 if the inbound connection is TCP without TLS, 443 if it is TLS)? Or is it an error? As far as I am aware, a port is always provided in practice. Maybe the answer is to explicitly require that the port number is always present and note that no default port can be supplied in this case as there is no scheme and therefore no associated default port.
cc NAME
NAME +1. This is the most natural outcome based on our established consensus in H2 and H3 that CONNECT requests is not accompanied by a scheme.
It's supposed to be a 400 error.
I verified that Apache mod_proxy will respond with 400 if there is no ":" or if the port is empty or non-numeric, and 403 if the port is not configured for use.
Is this something that needs to be listed as normatice change?

Related discussion:
text: most origin servers do not implement CONNECT. A client sending a CONNECT request MUST send the authority component <del> (described in Section 3.2 of RFC3986) as the request target; i.e., the request target consists of only the host name and port number of the tunnel destination, separated by a colon.  For example, </del> <ins> (described in RFC3986) as the request target, excluding userinfo but always with a port; i.e., the request target consists of only the host name and port number of the tunnel destination, separated by a colon.  For example, If the port is missing or invalid in the request target of a CONNECT request, the request MUST be rejected (typically, with a 400 (Bad Request) response). </ins> The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another
Code change:
I'm disappointed that RFC 6919 doesn't list "ARE EXPECTED TO".
Time for a bis?
In general, an unknown or new method can be handled by a resource by rejecting the request (with 406 for instance). However, some entities (intermediaries in particular) might be forced to engage with methods that are unknown to them. I couldn't find text in or Section 16.1 on this. However, the draft might benefit from advice on this. There are a few things that might be said, with reference to Section 9, which already says much of this: Intermediaries are expected to forward new methods. This enables the deployment of new methods. New methods might be safe, idempotent, or cacheable. Or they might not be. Actions taken need to consider this possibility and act accordingly. For instance, an intermediary that might be able to automatically retry a request cannot do so for an unknown method, which it does not know whether it is idempotent (9.2) or a cache can't cache a response unless the method is known to be cacheable (9.3).
PTAL. I don't think your second bullet is actionable; that's already clear in 16.1, and intermediaries aren't required to do any of those things.

Related discussion:
text: intermediary can enhance (or interfere) with either direction of the stream. <ins> Intermediaries are expected to forward messages even when protocol elements are not recognized (e.g., new methods, status codes, or field names), since that preserves extensibility for downstream recipients. </ins> An intermediary not acting as a tunnel MUST implement the header field, as specified in field.connection, and exclude fields
Code change:
It's written: Actually I'd rather say "MUST send a version no higher than their own in forwarded messages" (poor wording, I know, maybe someone can propose better). Indeed, if an intermediary receives an HTTP/1.0 request and passes it as HTTP/1.1, the server will wrongly assume that the client can deal with 1.1 (e.g. chunks) and the message may have to be degraded by the intermediary (such as de-chunking and rely on close only). Furthermore, seeing 1.0 for a server is often an indication of very limited (or possibly bogus) client. For example some intermediaries might avoid compressing or caching when facing HTTP/1.0 messages, and as such it's preferable to let such versions be properly advertised in messages that could be considered as potentially unsafe. Maybe a different wording should be "intermediaries... MUST NOT pass a message showing a version they do not support, and MUST make sure the message always conforms to the advertised version".
I agree with Willy: the underlying requirement is that intermediaries accept and send messages only in versions that they understand (unless acting as a tunnel, I guess). The original text basically means that, even if it is phrased in terms of what value is placed in a specific field rather than as the true requirement.
Discussed at Feb 21 interim; should work on a proposal to loosen this somewhat, at least for intermediaries. SHOULD + context?
OK let's try with that.
but see feedback from NAME

Related discussion:
text: Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version <del> in forwarded messages.  In other words, they are not allowed to blindly forward the </del> <ins> in forwarded messages, unless it is purposefully downgraded as a workaround for an upstream issue.  In other words, an intermediary is not allowed to blindly forward the </ins> without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the