jiebi/TextFlow huggingface dataset:
Original 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>  The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another

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

Revised text:
most origin servers do not implement CONNECT. A client sending a CONNECT request MUST send the authority component  <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
Original text:
intermediary can enhance (or interfere) with either direction of the stream.  An intermediary not acting as a tunnel MUST implement the header field, as specified in field.connection, and exclude fields

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

Revised 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
Original 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>  without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the

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

Revised text:
Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version  <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
Original text:
seconds (see delta-seconds). Although it is defined as a singleton header field, a cache <del> encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. </del>  <del> If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </del>  The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Reviewer comments:
Apologies for the lateness, but going through , I think we need to adjust handling of invalid headers: Right now, it's that caches SHOULD treat responses with invalid values as stale. However: No cache tested treats a response with in this manner; all ignore the field. Only Fastly and Firefox treat a response with in this manner; the rest ignore the field. Interestingly, most caches do consider a response with to be stale, except for Apache and Chrome. We specify that the first field line should be used when multiple are present. That's almost universally adhered to (with one deviation by Safari), but we omit multiple values on the same field line from this rule (which are treated as invalids as per above). However: When that line is , all caches reuse the response. When that line is , only Safari and Apache reuse it. This suggests that we could align with current implementations and improve interoperability by: Specifying that invalid fields should be ignored, not make the response stale. This is nearly universal practice. Specifying that the first field value should be used when multiple can be parsed. This is also nearly universal practice.

Revised text:
seconds (see delta-seconds). Although it is defined as a singleton header field, a cache  <ins> encountering a message with a list-based Age field value SHOULD use the first member of the field value, discarding subsequent ones. </ins>  <ins> If the field value (after discarding additional members, as per above) is invalid (e.g., it contains something other than a non- negative integer), a cache SHOULD ignore the field. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.
Original text:
that time. The Expires field value is an HTTP-date timestamp, as defined in <del> http.date. </del>  For example

Reviewer comments:
has a number of caveats about date parsing that aren't mentioned in ; they should be referenced.

Revised text:
that time. The Expires field value is an HTTP-date timestamp, as defined in  <ins> http.date.  See also expiration.model for parsing requirements specific to caches. </ins> For example
Original text:
user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank".  The Referer header field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals

Reviewer comments:
defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.

Revised text:
user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank". <ins> The Referer header field value need not convey the full URI of the referring resource; a user agent MAY truncate parts other than the referring origin. </ins> The Referer header field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals
Original text:
supposed to be confidential (such as behind a firewall or internal to a secured service).  Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or <del> "data" URI.  A user agent MUST NOT send a </del>  <del> header field in an unsecured HTTP request if the referring page was received with a secure protocol.  See sensitive.information.in.uris for additional security considerations. </del>  Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests.  This has the

Reviewer comments:
defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.

Revised text:
supposed to be confidential (such as behind a firewall or internal to a secured service).  Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or  <ins> "data" URI.  A user agent SHOULD NOT send a header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent.  A user agent MUST NOT send a </ins>  <ins> header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol.  See sensitive.information.in.uris for additional security considerations. </ins> Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests.  This has the
Original text:
Framing and control data is sent first, followed by a header section containing fields for the headers table.  When a message includes <del> content, the content is sent after the header section and potentially interleaved with zero or more trailer sections containing fields for the trailers table. </del>  Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
Framing and control data is sent first, followed by a header section containing fields for the headers table.  When a message includes  <ins> content, the content is sent after the header section, potentially followed by a trailer section that might contain fields for the trailers table. </ins> Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while
Original text:
to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message <del> semantics, and trailer fields provide additional metadata that can be dropped (safely ignored) when not desired. </del>  Messages are intended to be

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message  <ins> semantics, and trailer fields provide optional metadata that was unknown prior to sending the content. </ins> Messages are intended to be
Original text:
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1 <del> chunked transfer coding as a single trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.  However, multiple trailer sections interleaved with content have only been deployed as frame extensions. </del>  6.1.

Reviewer comments:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

Revised text:
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1  <ins> chunked transfer coding as a trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream. </ins> 6.1.