jiebi/TextFlow huggingface dataset:
Original text:
content, or poison a cache.  See security.considerations for security considerations regarding message routing.  7.5. A connection might be used for multiple request/response exchanges.

Reviewer comments:
I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.

Revised text:
content, or poison a cache.  See security.considerations for security considerations regarding message routing. <ins> The status code in a response indicates that the origin server has rejected the request because it appears to have been misdirected (status.421). </ins> 7.5. A connection might be used for multiple request/response exchanges.
Original text:
15.5.20.  The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a

Reviewer comments:
I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.

Revised text:
15.5.20. <ins> The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI.  A 421 is sent when an origin server (or gateway acting on behalf of the origin server) rejects a target URI that does not match an for which the server has been configured (origin) or does not match the connection context over which the request was received (routing.reject). A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service RFC7838. A proxy MUST NOT generate a 421 response. A 421 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness). 15.5.21. </ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a
Original text:
contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. <del> 15.5.21. </del>  The

Reviewer comments:
I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.

Revised text:
contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.  <ins> 15.5.22. </ins> The
Original text:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code)  422 Unprocessable Payload (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)

Reviewer comments:
I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.

Revised text:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <ins> 421 Misdirected Request (status code) </ins> 422 Unprocessable Payload (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)
Original text:
content, or poison a cache.  See security.considerations for security considerations regarding message routing.  7.5. A connection might be used for multiple request/response exchanges.

Reviewer comments:
This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.

Revised text:
content, or poison a cache.  See security.considerations for security considerations regarding message routing. <ins> The status code in a response indicates that the origin server has rejected the request because it appears to have been misdirected (status.421). </ins> 7.5. A connection might be used for multiple request/response exchanges.
Original text:
15.5.20.  The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a

Reviewer comments:
This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.

Revised text:
15.5.20. <ins> The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI.  A 421 is sent when an origin server (or gateway acting on behalf of the origin server) rejects a target URI that does not match an for which the server has been configured (origin) or does not match the connection context over which the request was received (routing.reject). A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service RFC7838. A proxy MUST NOT generate a 421 response. 15.5.21. </ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a
Original text:
contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. <del> 15.5.21. </del>  The

Reviewer comments:
This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.

Revised text:
contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.  <ins> 15.5.22. </ins> The
Original text:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code)  422 Unprocessable Payload (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)

Reviewer comments:
This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.

Revised text:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <ins> 421 Misdirected Request (status code) </ins> 422 Unprocessable Payload (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)
Original text:
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information <del> systems.  This document defines the semantics shared by all versions of HTTP, including its architecture, terminology, core protocol elements, and extensibility mechanisms, along with the "http" and </del>  "https" Uniform Resource Identifier (URI) schemes. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC

Reviewer comments:
For
In the abstract: "semantics... including its architecture, terminology..." seems incorrect; suggest "semantics... and its architecture..."
I always find possessive for "HTTP" a little hard to handle.

Revised text:
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information  <ins> systems.  This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions.  In this definition are core protocol elements, extensibility mechanisms, and the "http" and </ins> "https" Uniform Resource Identifier (URI) schemes. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
Original text:
that controls its message storage, retrieval, and deletion.  A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.  Any <del> client or server MAY employ a cache, though a cache cannot be used by a server while it is acting as a tunnel. </del>  The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response

Reviewer comments:
... full stop.
Also 500f337 (committed instead of PR'd, sorry; if we don't do this that will need to be backed out)

Revised text:
that controls its message storage, retrieval, and deletion.  A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.  Any  <ins> client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel. </ins> The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response
Original text:
3.4.  A shared cache MUST NOT use a cached response to a request with an header field (field.authorization) to satisfy any subsequent request

Reviewer comments:
so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.

Revised text:
3.4. <ins> A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (field.range).  After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per update. 3.5. </ins> A shared cache MUST NOT use a cached response to a request with an header field (field.authorization) to satisfy any subsequent request
Original text:
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). <del> 3.5. A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (field.range).  After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per update. </del> 4. When presented with a request, a cache MUST NOT reuse a stored

Reviewer comments:
so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.

Revised text:
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage).  4. When presented with a request, a cache MUST NOT reuse a stored
Original text:
RFC3040 (also commonly known as a <del> RFC1919 or ) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). </del>  Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate

Reviewer comments:
refers to a captive portal as a type of intermediary; we should make sure this aligns with the more recent CAPPORT drafts (IIRC current usage of that term is for the origin that the user is redirected to when captured; it's not an intermediary).
It is probably enough to strike "captive portal". "Interception proxy" will do, if "attacker" does not. The term was never something that RFC 7230 relied on and as you say the modern understanding of the term has evolved.

Revised text:
RFC3040 (also commonly known as a  <ins> RFC1919) differs from an HTTP proxy because it is not chosen by the client.  Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). </ins> Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate
Original text:
Content-Type header field cache cacheable <del> captive portal </del> client close complete

Reviewer comments:
refers to a captive portal as a type of intermediary; we should make sure this aligns with the more recent CAPPORT drafts (IIRC current usage of that term is for the origin that the user is redirected to when captured; it's not an intermediary).
It is probably enough to strike "captive portal". "Interception proxy" will do, if "attacker" does not. The term was never something that RFC 7230 relied on and as you say the modern understanding of the term has evolved.

Revised text:
Content-Type header field cache cacheable  client close complete
Original text:
payload data is allowed by requiring a Content-Length header field with a value of "0".  A new method definition needs to indicate whether it is safe (safe.methods), idempotent (idempotent.methods), cacheable (cacheable.methods), what semantics are to be associated with the

Reviewer comments:
Considerations for new method should mention that the target URI has to be absolute. from URL
+1, thanks for filing!
We currently say: Isn't that sufficiently clear?
It wasn't clear to me because I didn't read the whole doc when I was searching for this information.
It's weird to say this because a URI is always in absolute form (part of what makes it Uniform). Only a reference can be relative, like within the request-target of 1.1 (absolute-path) or anything called a URI-reference. I think what you want to add is a reminder that new method extensions cannot use the host:port or asterisk forms of request target. Note that this only requires a request target in absolute form if the scheme or host:port are necessary to define the target, which they are for CONNECT-UDP.

Revised text:
payload data is allowed by requiring a Content-Length header field with a value of "0". <ins> Likewise, new methods cannot use the special host:port and asterisk forms of request target that are allowed for and , respectively (target.resource).  A full URI in absolute form is needed for the target URI, which means either the request target needs to be sent in absolute form or the target URI will be reconstructed from the request context in the same way it is for other methods. </ins> A new method definition needs to indicate whether it is safe (safe.methods), idempotent (idempotent.methods), cacheable (cacheable.methods), what semantics are to be associated with the
Original text:
2.3. <del> When a received protocol element is parsed, the recipient MUST be able to parse any value of reasonable length that is applicable to the recipient's role and that matches the grammar defined by the corresponding ABNF rules.  Note, however, that some received protocol elements might not be parsed.  For example, an intermediary forwarding a message might parse a field into generic field name and field value components, but then forward the field without further parsing inside the field value. </del>  HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will

Reviewer comments:
This MUST is very fuzzy, and obviously isn't testable. Should it just be prose?
Not convinced, but wouldn't object. Maybe "needs to"?
That's what makes the ABNF normative. I don't see a need to change it now.
Sorry, what does the ABNF have to do with this? The issue is the phrase "MUST be able to parse any value of reasonable length", where "reasonable length" is not defined.
It is defined as being reasonable. I have no problem testing that (subjectively). ;-)
I meant the second half.
How about
I like it

Revised text:
2.3.  <ins> A recipient SHOULD parse a received protocol element defensively, with only marginal expectations that the element will conform to its ABNF grammar and fit within a reasonable buffer size. </ins> HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will