jiebi/CodeConvo huggingface dataset:
Code change:
NAME PTAL.
Client/Server Messaging still is HTTP/1.1-specific. Suggested deletions below: Also, trailers?
Textual reason-phrase is also 1.1 specific.
NAME what's the implication of that? It's already suggested to be deleted.
It wasn't in a previous iteration of your suggestion -- see your edit history. Perhaps we noticed this in parallel?
Ah ;)
Somewhat related is .
This text seems out of place in 3.2 Storing Responses to Authenticated Requests. It also omits .
It seems like it's covered by 4.2.4 pretty completely.

Related discussion:
text: A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the
Code change:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Related discussion:
text: negotiation. This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC <del> 7615, and portions of RFC 7230. </del> <ins> 7538, RFC 7615, and portions of RFC 7230. </ins> Editorial Note
Code change:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Related discussion:
text: changes being summarized in changes.from.rfc.7230.  The other parts of RFC7230 are obsoleted by "HTTP/1.1 Messaging" Messaging.  This document also obsoletes RFC7231 (see changes.from.rfc.7231), RFC7232 <del> (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), and RFC7233 (see changes.from.rfc.7235), and RFC7615 (see changes.from.rfc.7615). </del> <ins> (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), RFC7233 (see changes.from.rfc.7235), RFC7233 (see changes.from.rfc.7538), and RFC7615 (see changes.from.rfc.7615). </ins> 1.1.
Code change:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Related discussion:
text: A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the
Code change:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Related discussion:
text: contains a short hypertext note with a hyperlink to the different URI(s). <ins> 9.4.9. The status code indicates that the has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible. The server SHOULD generate a header field in the response containing a preferred URI reference for the new permanent URI.  The user agent MAY use the Location field value for automatic redirection.  The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s). A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness). </ins> 9.5. The
Code change:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Related discussion:
text: 305 Use Proxy (status code) 306 (Unused) (status code) 307 Temporary Redirect (status code) <ins> 308 Permanent Redirect (status code) </ins> 3xx Redirection (status code class) 4
Code change:
I had in mind something a little more general, that would include fields which are defined like Vary:

Related discussion:
text: authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. <del> A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). </del> <ins> Aside from the well-known exception noted below, a sender MUST NOT generate multiple header fields with the same field name in a message, or append a header field when a field of the same name already exists in the message, unless that field's definition allows multiple field values to be recombined as a comma-separated list [i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values)]. </ins> A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the
Code change:
Note that there's one more reference to pragma remaining, but that will be taken care of by .
... is still hanging around, and even less relevant. We still recommend sending it in certain circumstances; can we drop that?
Specifically: [ ] In Constructing Responses from Caches -- although see [ ] In Pragma, "When sending a no-cache request, a client ought to include both the pragma and cache-control directives" [ ] In Pragma, "When the Cache-Control header field is not present in a request, caches must consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present" Proposal: Change s registration status to "obsoleted" Remove requirements relating to it. Retain text explaining its semantics, and note that it's superseded by .
BTW, I'm comfortable doing this because we're getting rid of requirements on request CC anyway -- see .
I have a few editorial changes to suggest here to make it more readable and remove the trailing note, but it is probably easier to commit this as is and we can tweak it later.

Related discussion:
text: 5.4. <del> The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as </del> <ins> The "Pragma" header field was defined for HTTP/1.0 caches, so that clients could specify a "no-cache" request (as </ins> <del> was not defined until HTTP/1.1).  When the Cache-Control header field is also present and understood in a request, Pragma is ignored. </del> <ins> was not defined until HTTP/1.1). </ins> <del> In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients.  This specification deprecates such extensions to improve interoperability. When the header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see cache-request-directive). When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other request directives at HTTP/1.1 or greater caches.  For example: will constrain HTTP/1.1 and greater caches to serve a response no older than 30 seconds, while precluding implementations that do not understand from serving a cached response. </del> <ins> However, support for Cache-Control is now widespread.  As a result, this specification deprecates Pragma. </ins> 5.5.
Code change:
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.

Related discussion:
text: by a secondary key for the values of the original request's selecting header fields (caching.negotiated.responses). <ins> A cache is when it cannot contact the origin server or otherwise find a forward path for a given request.  A disconnected cache can serve stale responses in some circumstances (serving.stale.responses). </ins> 3. A cache MUST NOT store a response to any request, unless:
Code change:
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.

Related discussion:
text: applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive). <del> A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). </del> <ins> A cache MUST NOT send stale responses unless it is disconnected or doing so is explicitly allowed (e.g., by the max-stale request directive; see cache-request-directive). </ins> 4.3.
Code change:
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.

Related discussion:
text: The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a <del> cache cannot reach the origin server for any reason, it MUST generate a </del> <ins> cache is disconnected, it MUST generate a </ins> response.
Code change:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Related discussion:
text: 12.1. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the two tables of </del> <ins> Please update the "Hypertext Transfer Protocol (HTTP) Header Field Registry" registry at <https://www.iana.org/assignments/http-headers> with the header field names listed in the two tables of </ins> header.fields. 12.2.
Code change:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Related discussion:
text: 4.1.1. <del> HTTP header fields are registered within the "Message Headers" registry located at <https://www.iana.org/assignments/message- headers>, as defined by BCP90, with the protocol "http". </del> <ins> The "Hypertext Transfer Protocol (HTTP) Header Field Registry" defines the namespace for HTTP header field names Any party can request registration of a HTTP header field.  See considerations.for.new.header.fields for considerations to take into account when creating a new HTTP header field. The "HTTP Header Field Name" registry is located at "https://www.iana.org/assignments/http-headers/".  Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Header field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Header fields with the status 'permanent' are Specification Required (using terminology from RFC8126). Registration requests consist of at least the following information: The Expert(s) can define additional fields to be collected in the registry, in consultation with the community. Standards-defined names have a status of "permanent".  Other names can also be registered as permanent, if the Expert(s) find that they are in use, in consultation with the community.  Other names should be registered as "provisional". Provisional entries can be removed by the Expert(s) if -- in consultation with the community -- the Expert(s) find that they are not in use.  The Experts can change a provisional entry's status to permanent at any time. Note that names can be registered by third parties (including the Expert(s)), if the Expert(s) determines that an unregistered name is widely deployed and not likely to be registered in a timely manner otherwise. </ins> 4.1.2.
Code change:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Related discussion:
text: requiring prior update of deployed intermediaries. All defined header fields ought to be registered with IANA in the <del> "Message Headers" registry. </del> <ins> "HTTP Header Field Name" registry. </ins> 4.1.3.
Code change:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Related discussion:
text: 13.4. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the table of field.names. </del> <ins> Please create a new registry as outlined in field.name.registry. After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to be moved to it, with the following changes applied: Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP header field registrations have moved, with an appropriate link. After that is complete, please update the registry with the header field names listed in the table of field.names. </ins> 13.5.
Code change:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Related discussion:
text: 8.1. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the table of </del> <ins> Please update the "Hypertext Transfer Protocol (HTTP) Header Field Registry" registry at <https://www.iana.org/assignments/http-headers> with the header field names listed in the two tables of </ins> header.field.definitions. 8.2.
Code change:
I also suggest closing here : the main reason for getting data without a request is an error reported by the server before closing (e.g. 408). Another reason may be a server implementation issue (extra CRLF, inconsistent multiple content-length, inconsistent content-length+transfer-encoding, user-fed incorrect error message). In all these cases the message delimitation is wrong and unrecoverable. Thus the client trying to "fix" it will in the best case be useless (close following), and in the worst case have nasty side effects. In haproxy the only case we try to address is the extra CRLF that a few old servers send slightly after data. If extra bytes are sent immediately after data, we close. If the extra CRLF happens slightly later, we find it while parsing the next response and the CRLF is silently skipped.
Everyone OK with this now?
Well, like Roy, I'd even prefer a MUST close, but I can live with a SHOULD.
It doesn't seem to account for the extra CRLF case. Maybe just add "... unless the data is limited to CRLF"?
CR and CRLF?
I was thinking the same but hesitating. BTW NAME it would be LF and CRLF. But quite frankly we could stick to CRLF only since it's the only known bogus pattern widely deployed in field.
updated.

Related discussion:
text: ) response. <ins> If an HTTP/1.1 client receives data on a connection that doesn't have any outstanding requests, it MUST NOT consider them to be a response to a not-yet-issued request; it SHOULD close the connection, since message delimitation is now ambiguous, unless the data consists only of one or more CRLF (which can be discarded, as per message.parsing). </ins> 9.4. HTTP/1.1 defaults to the use of "
Code change:
Also: change scripts that BAP is invoked with correct options. Note: I did not use "%i" for case-insensitive strings as this is the default anyway. If there is confusion about how a certain protocol element is matched, we should re-state that IMHO in the prose. The collected ABNF uses non-extended ABNF syntax. If this is a problem I'll need to do a bit more work on the tooling.
Should we just adopt wherever we use a string?
Yes, I think that's what the IESG wants us to do. (We were directed to use it in alt-svc)
I've started a branch (mnot-133). Question: do we want to convert things like this: into: ? We do that a fair amount for case-sensitive strings.
Yes. Let me take care of this.
+1
OK. I'll leave my branch there if you want to start with it; otherwise feel free to delete it.
FWIW, I'd prefer to do this only in the places where the string actually is case-sensitive.
I guess I forgot to close the ticket.
Looks good to me. I checked and we also say that they're case-sensitive in the accompanying prose for each instance (although for weak ETags, it's a bit far away).

Related discussion:
text: 1.2. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in abnf.extension, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del> <ins> notation of RFC5234, extended with the notation for case-sensitivity in strings defined in RFC7405. It also uses a list extension, defined in abnf.extension, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </ins> collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation.