jiebi/CodeConvo huggingface dataset:
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and <del> encodings. </del> <ins> encodings.  Because of the line length limitations, field values within message/http are allowed to use line folding ( ), as described in line.folding, to convey the field value over multiple lines.  A recipient of message/http data MUST replace any obsolete line folding with one or more SP characters when the message is consumed. </ins> 10.2.
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: 8859-1, supporting other charsets only through use of RFC2047 encoding.  Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB.  A recipient <del> SHOULD treat other octets in field content (obs-text) as opaque data. </del> <ins> SHOULD treat other allowed octets in field content (i.e., </ins> <del> Field values containing CR or NUL characters are invalid and </del> <ins> ) as opaque data. Field values containing CR, LF, or NUL characters are invalid and </ins> dangerous, due to the varying ways that implementations might parse <del> and interpret those characters; a recipient of CR or NUL within a field value MUST either reject the message or replace each of those </del> <ins> and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those </ins> characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake <del> of robustness if they only appear within safe field value contexts (e.g., opaque data). </del> <ins> of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser). </ins> Fields that only anticipate a single member as the field value are referred to as
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string. <del> Historically, HTTP field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab ( ).  This document assumes that any such obsolete line folding has been removed prior to interpreting the field value (e.g., as described in line.folding). </del> 5.6. 5.6.1.
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: 8.8. <del> Validator fields convey metadata about the </del> <ins> Resource metadata is referred to as a if it can be used within a precondition (preconditions) to make a conditional request (conditional.requests).  Validator fields convey a current validator for the (representations). </ins> <del> (representations).  In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response.  Note that, depending on the status code </del> <ins> In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response.  Note that, depending on the method and status code </ins> semantics, the for a given response is not necessarily the same as the
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: For example, an ETag field in a response communicates the entity-tag of the newly created resource's <del> representation, so that it can be used in later conditional requests to prevent the "lost update" problem (preconditions). </del> <ins> representation, so that the entity-tag can be used as a validator in later conditional requests to prevent the "lost update" problem. </ins> This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions:
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: (field.etag).  Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning WEBDAV, that are beyond the scope of this <del> specification.  A resource metadata value is referred to as a when it is used within a precondition. </del> <ins> specification. </ins> 8.8.1.
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: >> Response: <del> 8.8.4. In responses to GET or HEAD, an origin server: In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a value in successful responses to a retrieval request. A client: </del> 9. 9.1.
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: indicated by the method definition or explicit cache controls (see heuristic.freshness). <ins> In 200 responses to GET or HEAD, an origin server SHOULD send any available validator fields (response.validator) for the , with both a strong entity-tag and a date being preferred. In 200 responses to state-changing methods, any validator fields (response.validator) sent in the response convey the current validators for the new representation formed as a result of successfully applying the request semantics.  Note that the PUT method (PUT) has additional requirements that might preclude sending such validators. </ins> 15.3.2. The
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: header field is received, by the target URI. The 201 response content typically describes and links to the <del> resource(s) created.  See response.validator for a discussion of the meaning and purpose of validator fields, such as and , in a 201 response. </del> <ins> resource(s) created.  Any validator fields (response.validator) sent in the response convey the current validators for a new representation created by the request.  Note that the PUT method (PUT) has additional requirements that might preclude sending such validators. </ins> 15.3.3.
Code change:
Reviewer: Marco Tiloca Review result: Ready with Nits Thanks for this document! I have found it very well written and I believe it's basically ready. Please, see below some minor comments and nits. Best, /Marco [X] [Section 1.2] As to "absolute-path", it is more precise to point to Section 4.1 of [HTTP]. Editors: URL [X] [Section 3] "HTTP does not place a predefined limit on the length of a request-line, as described in Section 2 of [HTTP]" This can better point to Section 2.3 of [HTTP]. Editors: URL [X] [Section 3.2] "A client MUST send a Host header field in all HTTP/1.1 request messages." This sentence can be expanded to point to Section 7.2 of [HTTP]. "... excluding any userinfo subcomponent and its "NAME delimiter ..." This should point to Section 4.2.4 of [HTTP]. Editors: URL [X] [Section 3.3] "Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client." Is "client" actually the intended word here? Or is it about using redirection to explain the client how to obtain something else (e.g. a proper authority component for a follow-up request) ? Editors: client is the intended word here: this case is only possible if the client sent an HTTP/0.9 or HTTP/1.0 request without a Host header field, which should not be in any deployed client since 1995. [X] [Section 7.1.2] I believe it's better for the reader if the last paragraph is split into 2 or 3 sentences Editors: [X] [Section 9.8] "When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received ..." Shouldn't this be about received responses? Or does it refer to the completion of the exchanges started by the mentioned requests? Editors: yes, it's about the completion of the exchanges. [X] [Appendix A] The first paragraph can better point to Section 5.6.1 of [HTTP]. Editors: URL The reference for "absolute-path" should be Section 4.1 of [HTTP]. Editors: URL
Long indeed. NAME - do you want to give that a try?

Related discussion:
text: deliberately crafted to bypass security filters along the request chain. <del> A client MUST send a Host header field in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (http.uri).  If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. </del> <ins> A client MUST send a header field (field.host) in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (http.uri). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. </ins> A server MUST respond with a
Code change:
The text in the document says: The Media Type Designated Experts' suggested to make that stronger, and have the following note on the : Let's agree on either "discouraged" or "prohibited", and align the text in the document and in the IANA registry note.
I believe what the IANA registry says is good, so what's left to do is to align our spec text with that. My understanding is that no new text in the IANA Considerations is needed, as the change to the registry already happened.
If we agree to add the reference to this RFC in the IANA note, once the RFC is published, I can ask IANA to do that.
Good point. We could add that to the IANA Considerations. Should I?
I think that would make sense. Let's hear from others.

Related discussion:
text: information in multipart.byteranges for the media type "multipart/ byteranges". <ins> Furthermore please update the registry note about "q" parameters with a link to field.accept of this document. </ins> 18.9. Please update the "Service Name and Transport Protocol Port Number"
Code change:
Inspired by my ballot comments ( ) I started trying to write something about how it's required to send "close_notify" in normal connection shutdown, but didn't like how that worked, and ended up here. I am not sure if I regressed in some other axes while improving on this one, though.

Related discussion:
text: 9.8. <del> TLS provides a facility for secure connection closure through an exchange of closure alerts prior to closing a connection TLS13.  When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. </del> <ins> TLS uses an exchange of closure alerts prior to (non-error) connection closure to provide secure connection closure; see TLS13. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. </ins> When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message
Code change:
The follow-up discussion on indicated that the nature of the updates to RFC 3864 is essentially a "partial obsoletes", which means that we do not want to be part of BCP 90 even if we could -- we're carving off a piece of it and branching out on our own. This PR attempts to reword the description slightly to indicate that we're not just tweaking part of RFC 3864, but rather replacing part of it (the parts that relate to HTTP), hopefully without bloating the text too much.

Related discussion:
text: This specification updates the HTTP related aspects of the existing registration procedures for message header fields defined in RFC3864. <del> It defines both a new registration procedure and moves HTTP field definitions into a separate registry. </del> <ins> It replaces the old procedures as they relate to HTTP, by defining a new registration procedure and moving HTTP field definitions into a separate registry. </ins> Please create a new registry as outlined in fields.registry.