jiebi/TextFlow huggingface dataset:
Original text:
A server tests whether a content-coding for a given representation is acceptable using these rules:  An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content-coding in response.  If an Accept-Encoding header field is present in a request

Reviewer comments:
…levant when some of the acceptable ones are redundant (
However, from item 4 implies otherwise. I think that this only applies if the server wishes to choose between codings, as opposed to apply them all. Compression codings are usually mutually exclusive, but other codings are not necessarily. Splitting this point into a paragraph might be the way to resolve this:
See also URL

Revised text:
A server tests whether a content-coding for a given representation is acceptable using these rules: <ins> A representation could be encoded with multiple content codings. However, most content codings are alternative ways to accomplish the same purpose (e.g., data compression).  When selecting between multiple content codings that have the same purpose, the acceptable content coding with the highest non-zero qvalue is preferred. </ins> An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content-coding in response.  If an Accept-Encoding header field is present in a request
Original text:
The status code indicates that one or more conditions given in the <del> request header fields evaluated to false when tested on the server. This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. </del>  15.5.14.

Reviewer comments:
I wasn't sure where exactly to include the citation, but the end of the sentence seemed harmless.

Revised text:
The status code indicates that one or more conditions given in the  <ins> request header fields evaluated to false when tested on the server (conditional.requests).  This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. </ins> 15.5.14.
Original text:
allow the underlying transport's flow-control mechanisms to resolve temporary overloads, rather than terminate connections with the expectation that clients will retry.  The latter technique can <del> exacerbate network congestion. </del>  A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request.  If the

Reviewer comments:
The section was talking about server load as well, but it doesn't mention that being a cost of closing connections.
I thought that the assumption was OK-ish: the expectation that clients will retry. That said, I agree that this entire thing could be better. I was looking for a minimal fix.

Revised text:
allow the underlying transport's flow-control mechanisms to resolve temporary overloads, rather than terminate connections with the expectation that clients will retry.  The latter technique can  <ins> exacerbate network congestion or server load. </ins> A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request.  If the
Original text:
" (content.negotiation). <del> This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. </del>  This document obsoletes the portions of RFC7230 that are independent of the HTTP/1.1 messaging syntax and connection management, with the

Reviewer comments:
draft-ietf-httpbis-semantics says in the intro: the multipart/byteranges media type. Is this truly something specific to 1.1? Are there difference in other versions?
Good catch.
okay (editorial)

Revised text:
" (content.negotiation).  <ins> This document defines HTTP range requests, partial responses, and the multipart/byteranges media type. </ins> This document obsoletes the portions of RFC7230 that are independent of the HTTP/1.1 messaging syntax and connection management, with the
Original 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>  If the final response to the last request on a connection has been completely received and there remains additional data to read, a user

Reviewer comments:
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.

Revised text:
server is unable or unwilling to buffer the entire request before processing.  <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
Original 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>  9.

Reviewer comments:
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.

Revised 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  <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.
Original 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>  There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large organizations.

Reviewer comments:
In , Section 2 of -caching is cited. But it would seem like the entire document is a better reference here.

Revised 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  <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.
Original text:
not include content, the Content-Length indicates the size of the selected representation (field.content-length).  6.3. The length of a message body is determined by one of the following

Reviewer comments:
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.

Revised 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
Original 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

Reviewer comments:
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.

Revised text:
An example is  A user agent SHOULD send a Content-Length in a request message when no
Original 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>  Charset names ought to be registered in the IANA "Character Sets" registry (<https://www.iana.org/assignments/character-sets>)

Reviewer comments:
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).

Revised text:
HTTP uses  <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>)
Original 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>  If a request target is subject to content negotiation, the cache might store multiple responses for it.  Caches differentiate these

Reviewer comments:
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

Revised text:
The  <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
Original 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>  One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see

Reviewer comments:
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 :)

Revised text:
7.1.  <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
Original text:
programs perform for a particular connection.  The same program might act as a client on some connections and a server on others.  3.4. HTTP is a stateless request/response protocol for exchanging

Reviewer comments:
The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'

Revised 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
Original 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

Reviewer comments:
The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'

Revised text:
allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.  3.8. A
Original text:
grammar aside from the robustness exceptions listed above, the server SHOULD respond with a <del> response. </del>  2.3.

Reviewer comments:
After "the server SHOULD respond with a 400 (Bad Request) response" I'd add "and close the connection" as it's not necessarily obvious to everyone.

Revised text:
grammar aside from the robustness exceptions listed above, the server SHOULD respond with a  <ins> response and close the connection. </ins> 2.3.
Original 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>  HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and

Reviewer comments:
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.

Revised 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  <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
Original 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>  10.1.3.

Reviewer comments:
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

Revised text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or  <ins> authentication. </ins> 10.1.3.
Original 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>  HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and

Reviewer comments:
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.

Revised 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  <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