jiebi/TextFlow huggingface dataset:
Original text:
When a message does not have a <del> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for potential content.  For messages that do include content, the Content-Length field value provides the framing information necessary for determining where the data (and message) ends.  For messages that do not include content, the Content-Length indicates the size of the </del>  selected representation (field.content-length). A sender MUST NOT send a Content-Length header field in any message

Reviewer comments:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Revised text:
When a message does not have a  <ins> header field, a Content-Length header field (field.content-length) can provide the anticipated size, as a decimal number of octets, for potential content.  For messages that do include content, the Content-Length field value provides the framing information necessary for determining where the data (and message) ends.  For messages that do not include content, the Content-Length indicates the size of the </ins> selected representation (field.content-length). A sender MUST NOT send a Content-Length header field in any message
Original text:
The <del> of request-target is only used for CONNECT requests (CONNECT). </del>  When making a CONNECT request to establish a tunnel through one or <del> more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target.  For example, </del>  3.2.4.

Reviewer comments:
In 3.2.3. authority-form it says Whereas it needs to specifically require host:port, as in the definition of :
does this merit a change log entry?

Revised text:
The  <ins> of request-target is only used for CONNECT requests (CONNECT).  It consists of only the and number of the tunnel destination, separated by a colon (":"). </ins> When making a CONNECT request to establish a tunnel through one or  <ins> more proxies, a client MUST send only the host and port of the tunnel destination as the request-target.  The client obtains the host and port from the target URI's component, except that the scheme's default port is sent if the target URI elides the port.  For example, a CONNECT request to "http://www.example.com" looks like </ins> 3.2.4.
Original text:
Transfer-Encoding header fields received in a successful response to CONNECT. <del> Content within a CONNECT request message has no defined semantics; sending content in a CONNECT request might cause some existing implementations to reject the request. </del>  Responses to the CONNECT method are not cacheable.

Reviewer comments:
The spec currently says this about data sent along with a CONNECT request: Is there a demarcation between data "within" a request and data to be sent on the tunnel if it opens successfully? HTTP/2 and HTTP/3 are fairly specific that all DATA frames are data for the tunnel. Do we need to say anything about the client prospectively sending data before the proxy responds?
We should decide what we want to allow. If HTTP/3 is going to send CONNECT data within HTTP/3 frame payloads after (or before) the recipient accepts the CONNECT, then we should specify it differently than how we specified CONNECT in 1.1. I am fine with that.
Hm. Does this imply we special-case 1.1, and require the HTTP/2/3 behaviour for new versions?
I think it is already a special case for 1.1, so that's not a problem.
OK, let me rephrase this then :-). Are we trying to make it consistent for all "new" versions?
Given that CONNECT is specified on a version-by-version basis anyway, I think I'd rephrase it with something like this: CONNECT is one of those weird edges of the protocol where each version will have to respecify its behavior; we don't necessarily need to prescribe what it will be, just make allowances for versions to differ.

Revised text:
Transfer-Encoding header fields received in a successful response to CONNECT.  <ins> A CONNECT request message does not have content.  The interpretation of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.
Original text:
HTTP/1.1 defaults to the use of , allowing multiple requests and responses to be carried over a <del> single connection.  The " " connection option is used to signal that a connection will not persist after the current request/response.  HTTP implementations SHOULD support persistent connections. </del>  A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and

Reviewer comments:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Revised text:
HTTP/1.1 defaults to the use of , allowing multiple requests and responses to be carried over a  <ins> single connection.  HTTP implementations SHOULD support persistent connections. </ins> A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and
Original text:
A client that does not support <del> MUST send the "close" connection option in every request message. </del>  A server that does not support <del> MUST send the "close" connection option in every response message that does not have a </del>  status code. A client MAY send additional requests on a persistent connection <del> until it sends or receives a " </del>  <del> " connection option or receives an HTTP/1.0 response without a "keep- </del>  alive" connection option. In order to remain persistent, all messages on a connection need to

Reviewer comments:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Revised text:
A client that does not support  <ins> MUST send the connection option in every request message. </ins> A server that does not support  <ins> MUST send the connection option in every response message that does not have a </ins> status code. A client MAY send additional requests on a persistent connection  <ins> until it sends or receives a </ins>  <ins> connection option or receives an HTTP/1.0 response without a "keep- </ins> alive" connection option. In order to remain persistent, all messages on a connection need to
Original text:
problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). <del> Note that the field name "Close" is reserved, since using that name as an HTTP header field might conflict with the "close" connection defined above. </del> See compatibility.with.http.1.0.persistent.connections for more information on backwards compatibility with HTTP/1.0 clients.

Reviewer comments:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Revised text:
problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).  See compatibility.with.http.1.0.persistent.connections for more information on backwards compatibility with HTTP/1.0 clients.
Original text:
directive (defined by RFC8246) instructs caches to forgo revalidation of fresh responses even when requested by the client. <del> Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources.  For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (RFC4918). </del> Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD

Reviewer comments:
without changing section numbering
implies that a precondition failure is a good safe mode. However, a precondition that isn't recognized by a server will not share this property. A server that does not recognize a header as a precondition will ignore it and likely proceed with handling the request even if the precondition expressed should have failed. Indeed, the same is true if a server ignores preconditions, though the specification effectively . is the only text I could find on defining new preconditions. (One thing I really want to avoid is server's applying special heuristics to headers that start with , because that is one of many poor outcomes if this is left.)
There is also the example in the section above that I suppose we could make a new section on precondition extensions, but they aren't a separate category (like If*). For example, my precondition proposal for 1.1 was an all-inclusive Unless that enclosed a logic bag (structured field value). Note that they have always depended on compliance-when-implemented, since I added the first (If-Modified-Since) in early 1994.
Does this need to be in this specification?
I think we're almost in the extension territory (I like the idea of a header field that lists the applicable precondition fields). As far as this specification goes, simply noting that new preconditions won't share properties of the core preconditions, in particular the expectation that it is understood by servers.
One grammatical nit.

Revised text:
directive (defined by RFC8246) instructs caches to forgo revalidation of fresh responses even when requested by the client.  Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD
Original text:
changes that were partially applied, and then automatically retrying the requests that failed. <del> Some clients use weaker signals to initiate automatic retries.  For example, when a POST request is sent, but the underlying transport connection is closed before any part of the response is received. Although this is commonly implemented, it is not recommended. </del>  A proxy MUST NOT automatically retry non-idempotent requests.  A client SHOULD NOT automatically retry a failed automatic retry.

Reviewer comments:
to clients that attempt to guess (editorial)
I have no idea what this is trying to say and it is 1.1-specific. I suggest we delete it.
It was added as part of URL, adressing .
How about
May end up encouraging this kind of implementation, by providing an example here ... ? Maybe just leave this as "Some clients take a riskier approach and attempt to guess when an automatic retry is possible because the original request may not have been received by the server." ....
I don't see any problem with the original text, but NAME your replacement is fine too (although the second sentence is a fragment).
How about

Revised text:
changes that were partially applied, and then automatically retrying the requests that failed.  <ins> Some clients take a riskier approach and attempt to guess when an automatic retry is possible.  For example, a client might automatically retry a POST request if the underlying transport connection closed before any part of a response is received, particularly if an idle persistent connection was used. </ins> A proxy MUST NOT automatically retry non-idempotent requests.  A client SHOULD NOT automatically retry a failed automatic retry.
Original text:
protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. <del> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </del>  Editorial Note

Reviewer comments:
I am seeing a lot of warnings about lines being too long (longer than 72 characters), but they are unrelated to these changes.
This changed "previous authors, editors, and Working Group Chairs" to "current and previous authors"; that's misleading, as it actually does not contain any current authors. Originally posted by NAME in URL
This is what I had in mind in terms of bringing back the original acks.

Revised text:
protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.  <ins> This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </ins> Editorial Note
Original text:
protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. <del> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </del>  Editorial Note

Reviewer comments:
Nits on semantics flags this: -- The draft header indicates that this document updates RFC3864, but the abstract doesn't seem to mention this, which it should.
Can you point to a document that states this?

Revised text:
protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.  <ins> This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </ins> Editorial Note
Original text:
and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency. <del> A content within a HEAD request message has no defined semantics; sending content in a HEAD request might cause some existing implementations to reject the request. </del>  The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the

Reviewer comments:
Should we leave these open until after IESG last call, or just apply them now?
Good Q. NAME ?
I think it'd be preferable to not cut another version until we get through the IETF last call. However, if we want to merge this and just keep a note of the changes, I don't see any issue.
I think it would be preferable, just to avoid people raising the same issues again, and also to get the Index into the last call version.
HEAD says whereas the new text for GET is and similarly for DELETE. We should update HEAD as well to be
Digging in the change logs: the text for GET comes from URL (with subsequent tuning).

Revised text:
and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency.  <ins> A client SHOULD NOT generate content in a HEAD request.  Content received in a HEAD request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling). </ins> The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the
Original text:
that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma <del> and </del>  <del> (optional whitespace).  For consistency, use comma SP. </del>  The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a

Reviewer comments:
Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.

Revised text:
that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma  <ins> (",") and optional whitespace ( </ins>  <ins> , defined in whitespace).  For consistency, use comma SP. </ins> The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a
Original text:
A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a <del> single comma (",") and optional whitespace (OWS). </del>  5.6.1.1.

Reviewer comments:
Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.

Revised text:
A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a  <ins> single comma (",") and optional whitespace ( , defined in whitespace). </ins> 5.6.1.1.
Original text:
for the <del> . </del>  GET is the primary mechanism of information retrieval and the focus <del> of almost all performance optimizations.  Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.  A successful response reflects the quality of "sameness" identified by the target URI.  In turn, constructing applications such that they produce a URI for each important resource results in more resources being available for other applications, producing a network effect that promotes further expansion of the Web. </del>  It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of

Reviewer comments:
LGTM.
Need to explain or reference explanation.
LGTM.
okay, I think this reads better, or we can split them into separate PRs if needed

Revised text:
for the  <ins> .  A successful response reflects the quality of "sameness" identified by the target URI (RFC3986).  Hence, retrieving identifiable information via HTTP is usually performed by making a GET request on an identifier associated with the potential for providing that information in a response. </ins> GET is the primary mechanism of information retrieval and the focus  <ins> of almost all performance optimizations.  Applications that produce a URI for each important resource can benefit from those optimizations while enabling their reuse by other applications, creating a network effect that promotes further expansion of the Web. </ins> It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of
Original text:
information. Other prefixes are sometimes used in HTTP field names; for example, <del> "Accept-" is used in many content negotiation headers.  These prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. </del>  16.3.2.2.

Reviewer comments:
I'm a little uneasy that the majority of headers that are prefixed with are actually scoped to the selected representation. E.g., , , , . The only registered, current headers that actually about the content (using the current definition in Semantics) are and , AFAICT. Not sure about ; it's defined in terms of the selected representation, but could equally be defined in terms of content, I suspect. It might help to add a small note to the that explains that the prefix doesn't necessarily imply that the header is strictly about the content. Also might be worth mentioning in the .
Reading semantics I have some doubts on C-L wrt partial representation this seems to be the full representation data (eg. see C-L + HEAD). But then what happens with value in a range response? The complete representation-data or the actual content?
"A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation. Each Content-Range header field includes information about the selected representation's complete length." So the case of a 206 response is special-cased.
It seems to me that C-L is more often used to convey "messaging" information, than the actual metadata (which happens only when HEAD is used).

Revised text:
information. Other prefixes are sometimes used in HTTP field names; for example,  <ins> "Accept-" is used in many content negotiation headers, and "Content-" is used as explained in content.  These prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. </ins> 16.3.2.2.