jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. <del> 15.5.21. </del> <ins> 15.5.22. </ins> The
Code change:
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.

Related discussion:
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)
Code change:
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.

Related discussion:
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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. <del> 15.5.21. </del> <ins> 15.5.22. </ins> The
Code change:
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.

Related discussion:
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)
Code change:
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.

Related discussion:
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> <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
Code change:
... full stop.
Also 500f337 (committed instead of PR'd, sorry; if we don't do this that will need to be backed out)

Related discussion:
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> <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
Code change:
so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.

Related discussion:
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
Code change:
so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
text: Content-Type header field cache cacheable <del> captive portal </del> client close complete
Code change:
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.

Related discussion:
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
Code change:
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

Related discussion:
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> <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
Code change:
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

Related discussion:
text: its own resources needs to be able to parse and process those same references when received as a target URI. <ins> Many received protocol elements are only parsed to the extent necessary to identify and forward that element downstream.  For example, an intermediary might parse a received field into its field name and field value components, but then forward the field without further parsing inside the field value. </ins> 2.4. A recipient MUST interpret a received protocol element according to
Code change:
There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.

Related discussion:
text: likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on <del> the received precondition header fields and their precedence, as defined in precedence.  The </del> <ins> the received precondition header fields and their precedence.  In summary, the </ins> and <del> conditional header fields are not applicable to a cache. </del> <ins> conditional header fields are not applicable to a cache, and takes precedence over . See precedence for a complete specification of precondition precedence. </ins> A request containing an