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

Related discussion:
text: seconds (see delta-seconds). Although it is defined as a singleton header field, a cache <del> encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. </del> <ins> encountering a message with a list-based Age field value SHOULD use the first member of the field value, discarding subsequent ones. </ins> <del> If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </del> <ins> If the field value (after discarding additional members, as per above) is invalid (e.g., it contains something other than a non- negative integer), a cache SHOULD ignore the field. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.
Code change:
defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.

Related discussion:
text: user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank". <ins> The Referer header field value need not convey the full URI of the referring resource; a user agent MAY truncate parts other than the referring origin. </ins> The Referer header field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals
Code change:
defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.

Related discussion:
text: supposed to be confidential (such as behind a firewall or internal to a secured service).  Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or <del> "data" URI.  A user agent MUST NOT send a </del> <ins> "data" URI.  A user agent SHOULD NOT send a header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent.  A user agent MUST NOT send a </ins> <del> header field in an unsecured HTTP request if the referring page was received with a secure protocol.  See sensitive.information.in.uris for additional security considerations. </del> <ins> header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol.  See sensitive.information.in.uris for additional security considerations. </ins> Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests.  This has the
Code change:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

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

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

Related discussion:
text: Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions.  For example, trailers were introduced within the HTTP/1.1 <del> chunked transfer coding as a single trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.  However, multiple trailer sections interleaved with content have only been deployed as frame extensions. </del> <ins> chunked transfer coding as a trailer section after the content.  An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream. </ins> 6.1.
Code change:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

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

Related discussion:
text: 6.5. <del> Fields (fields) that are sent/received after the header section has ended (usually after the content begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a </del> <ins> Fields (fields) that are located within a </ins> <del> .  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information. </del> <ins> are are referred to as "trailer fields" (or just "trailers", colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information. </ins> Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics
Code change:
I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.

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

Related discussion:
text: reflect the message received, excluding some fields described below, back to the client as the content of a <del> response with a of "message/http" (media.type.message.http).  The final recipient is either the origin server or the first server to receive a </del> <ins> response.  The "message/http" (media.type.message.http) format is one way to do so.  The final recipient is either the origin server or the first server to receive a </ins> value of zero (0) in the request (field.max-forwards).