jiebi/CodeConvo huggingface dataset:
Code change:
This text: URL a condition on the conformance requirement that suggests that clients that do know the server will support HTTP/1.1 (or later) can do something else. But it doesn't really address what constraints then apply. I think that this was just to permit the use of the chunked transfer encoding for delimiting the message body, but that does not follow. I think that this might be rephrased as follows:
It reads the same to me, but +1.

Related discussion:
text: server is unable or unwilling to buffer the entire request before processing. <del> A user agent that sends a request containing a message body MUST send a valid header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. </del> <ins> A user agent that sends a request that contains a message body MUST send either a valid header field or use the chunked transfer coding.  A client MUST NOT use the chunked transfer encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. </ins> If the final response to the last request on a connection has been completely received and there remains additional data to read, a user
Code change:
A response is incomplete if the TLS connection close was incomplete. Remove text about TLS reuse/resumption, which was very inconsistent. On the first, I removed a case of "partial closure" rather than "incomplete closure". I also linked the incomplete message handling section with the TLS connection closure section.
Apparently I'm not allow to link to after the fact. Sorry for not having done so in the opening comment.
This is okay, but the paragraph before your first change should be rewritten instead. I can fix that later.

Related discussion:
text: neither chunked transfer coding nor Content-Length is terminated by closure of the connection and, thus, is considered complete regardless of the number of message body octets received, provided <del> that the header section was received intact. </del> <ins> that the header section was received intact.  When using TLS, an incomplete close cannot be used to terminate a response this way; such a response is incomplete (see tls.connection.closure). </ins> 9.
Code change:
In , Section 2 of -caching is cited. But it would seem like the entire document is a better reference here.

Related discussion:
text: there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request.  HTTP requirements for cache behavior and <del> cacheable responses are defined in caching.overview. </del> <ins> cacheable responses are defined in Caching. </ins> There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large organizations.
Code change:
Good point.
I guess all the options are ugly. Should we leave the text wehre ut was and just apply the proposed change in URL ?
Does better belong in -messaging?
Into 6.2?
Seems like the best place, yeah.
NAME : URL
But I don't know what this accomplishes given the paragraph after this one also refers to Transfer-Encoding.This makes sense on its own (with Martin's adjustment). Still not thrilled about having transfer-codings in semantics.Thanks. Fairly simple fix here. I've suggested a tweak for Roy's concern (which I can't make a suggestion before because of GitHub limitations.

Related discussion:
text: not include content, the Content-Length indicates the size of the selected representation (field.content-length). <ins> A sender MUST NOT send a Content-Length header field in any message that contains a header field. </ins> 6.3. The length of a message body is determined by one of the following
Code change:
Good point.
I guess all the options are ugly. Should we leave the text wehre ut was and just apply the proposed change in URL ?
Does better belong in -messaging?
Into 6.2?
Seems like the best place, yeah.
NAME : URL
But I don't know what this accomplishes given the paragraph after this one also refers to Transfer-Encoding.This makes sense on its own (with Martin's adjustment). Still not thrilled about having transfer-codings in semantics.Thanks. Fairly simple fix here. I've suggested a tweak for Roy's concern (which I can't make a suggestion before because of GitHub limitations.

Related discussion:
text: An example is <del> A sender MUST NOT send a Content-Length header field in any message that contains a header field. </del> A user agent SHOULD send a Content-Length in a request message when no
Code change:
is deprecated due to the ubiquity of UTF-8, but the section makes no mention of UTF-8. This might be worth a mention.
It's only used for though and that section already mentions UTF-8. As does the Media Type section. Since is deprecated, perhaps the production should simply be removed and takes directly?
Accept-Charset is deprecated primarily for privacy. It also happens to be less useful now because of utf-8. In contrast, the charset parameter is still used most of the time, mainly to reduce sniffing. We can add something about utf-8, but promoting it too hard will cause other (social) problems.
NAME observation is correct. But then, charset is used in Content-Type as well, just not referenced directly as it is used over there as a regular parameter.
It's not clear to me at least that the production section also applies to .
Syntactically, it does not (because that relies on a more generic syntax for arbitrary parameters). But I agree, this needs cleanup.
Proposal is to remove the ABNF production and to clarify the text (so that it applies to Content-Type as well).

Related discussion:
text: HTTP uses <del> names to indicate or negotiate the character encoding scheme of a textual representation RFC6365.  A charset is identified by a case- insensitive token. </del> <ins> names to indicate or negotiate the character encoding scheme (RFC6365) of a textual representation.  In the fields defined by this document, charset names appear either in parameters ( ), or, for , in the form of a plain .  In both cases, charset names are matched case-insensitively. </ins> Charset names ought to be registered in the IANA "Character Sets" registry (<https://www.iana.org/assignments/character-sets>)
Code change:
This might be obvious, but the -caching draft never concretely says that a cache key is the information that a cache uses to select a single cached response. It just : "The cache key is comprised of, [...]"
LGTM

Related discussion:
text: The <del> is comprised of, at a minimum, the request method and target URI used to retrieve the stored response; the method determines under which circumstances that response can be used to satisfy a subsequent request.  However, many HTTP caches in common use today only cache GET responses, and therefore only use the URI as the cache key, forwarding other methods. </del> <ins> is the information a cache uses to select a response and is comprised of, at a minimum, the request method and target URI used to retrieve the stored response; the method determines under which circumstances that response can be used to satisfy a subsequent request.  However, many HTTP caches in common use today only cache GET responses, and therefore only use the URI as the cache key, forwarding other methods. </ins> If a request target is subject to content negotiation, the cache might store multiple responses for it.  Caches differentiate these
Code change:
A private cache that can be manipulated so that it mistakenly creates a cache entry might not have the reach of a shared cache, but it can still be a problem. Cache poisoning occurs when a cache can be written to by an entity other than the one that the cache would normally recognize as being authorized to write to it. Take the websocket poisoning where a cache misread a websocket stream as HTTP queries and established cached records under arbitrary origins. This would allow for poisoning of entries normally not controlled by the host that was using the websocket. Even though that might have been a single user affected by the poisoning, the effect was serious enough and motivated the inclusion of masking in websocket.
Simple :)

Related discussion:
text: 7.1. <del> Various attacks might be amplified by being stored in a shared cache. Such "cache poisoning" attacks use the cache to distribute malicious content to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </del> <ins> Various attacks might be amplified by being stored in a cache.  Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache.  This is especially effective when shared caches are used to distribute malicious content to many clients. </ins> One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see
Code change:
The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'

Related discussion:
text: programs perform for a particular connection.  The same program might act as a client on some connections and a server on others. <ins> HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </ins> 3.4. HTTP is a stateless request/response protocol for exchanging
Code change:
The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'

Related discussion:
text: allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies. <del> HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </del> 3.8. A
Code change:
Can you please factor the whitespace changes out into a separate PR?
Sorry, my editor did that without my knowledge. I didn't realize the draft was so messy to start with. Will do.
: This is good, but I think that the phrasing here could be more direct. "any semantic implied by the URI itself" - when you read suggests that you might infer something from a URI about what it does. However, I think that this underplays the key point. The point that should be made here is that a resource cannot decide to change the semantics of a method to suit its purposes (I guess unless it is willing to assume all responsibility for doing so, the usual caveat we apply here for things like request logging). Separately, the specific reference to 9.2.1 might be read to imply that safeness is special, but resources don't get to override the semantics of idempotent methods either (or any other well-defined properties of methods). So I would instead phrase this more directly and use the citation as an example only:
NAME can you PR that?
Sure.

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:
is saying something about using From for authentication, but I don't understand it: I think that this could be saying one of two things, maybe the latter: From contains only an unsupported claim about the identity of the generator of the message, so it can't be used for authentication. Including a From value that also contains a secret, such as a password, that could be used to authorize a request is unwise because recipients of the message won't necessarily treat the value as confidential and so the secret might leak. That latter is a bit strange, because an authorization could be bound to the specific request in various ways that might limit these risks. I can't tell because the logical chain between "this is who made the request" and use of the value for authorization isn't very well developed. It might be better to say nothing here instead.
My .02 - I think the intent was more the first -- just a warning that this is not an authentication mechanism to ward off the uninformed and optimistic. Given that this isn't widely used anyway, I don't think the text causes harm; I propose we just leave it as is.
Please, drop everything from "since" onward in that case. The reasoning makes no sense to me and the unsupported recommendation is clear enough.
+1

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:
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: 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:
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: act as a client on some connections and a server on others. HTTP is defined as a stateless protocol, meaning that each request <del> message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </del> <ins> message's semantics can be understood in isolation, and that the relationship between connections and messages on them has no impact on the interpretation of those messages.  For example, a CONNECT request (CONNECT) or a request with the Upgrade header field (field.upgrade) can occur at any time, not just in the first message on a connection.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. As a result, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </ins> 3.4.
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: 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.