jiebi/CodeConvo huggingface dataset:
Code change:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Related discussion:
text: 4xx Client Error 5xx Server Error safe <ins> section </ins> secured selected representation sender
Code change:
We should really mention this, as it's common and can cause misunderstanding. I also am likely to need to reference it in .
Maybe add a minimal explanation of "collapse"?

Related discussion:
text: Also, note that unsafe requests might invalidate already-stored responses; see invalidation. <ins> A response that is stored or storable can be used to satisfy multiple requests, provided that it is allowed to reuse that response for the requests in question.  This enables caches to "collapse" multiple incoming requests into a single forward request upon a cache miss, thereby reducing load on the origin server and network.  However, note that if the response returned is not able to be used for some or all of the collapsed requests, additional latency might be introduced, because they will need to be forwarded to be satisfied. </ins> When more than one suitable response is stored, a cache MUST use the most recent one (as determined by the
Code change:
says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.

Related discussion:
text: When there is more than one value present for a given directive (e.g., two <del> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid.  Caches are encouraged to consider responses that have invalid freshness information to be stale. </del> <ins> header field lines or multiple Cache-Control: max-age directives), either the first occurrence should be used, or the response should be considered stale.  If directives conflict (e.g., both max-age and no- cache are present), the most restrictive directive should be honored. Caches are encouraged to consider responses that have invalid freshness information (e.g., a max-age directive with non-integer content) to be stale. </ins> 4.2.2.
Code change:
says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.

Related discussion:
text: age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del> <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. 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. </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:
NAME It already is, this just changes how it's done.
My seem to indicate we might want to reconsider how . Of implementations that honour (two don't): none will consider invalid none will consider on two separate field lines invalid none will consider a duplicated value on two lines to make the header invalid if there are two header lines, all will consider only the first (and one, Safari, appears to use the min of them) none considers a non-numeric value to be invalid only Fastly and Firefox consider a non-negative integer to be invalid ... where invalid currently is required to be considered stale.

Related discussion:
text: age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del> <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. 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. </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:
I believe that we said this could be merged when Julian's issue was addressed, which Roy's suggestion did, so merging.
Some guidance about how and if new preconditions can be defined would be helpful. See .

Related discussion:
text: 15.3. <ins> HTTP's most widely used extensibility point is the definition of new header and trailer fields. New fields can be defined such that, when they are understood by a recipient, they override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses. However, defining a field doesn't guarantee its deployment or recognition by recipients.  Most fields are designed with the expectation that a recipient can safely ignore (but forward downstream) any field not recognized.  In other cases, the sender's ability to understand a given field might be indicated by its prior communication, perhaps in the protocol version or fields that it sent in prior messages, or its use of a specific media type.  Likewise, direct inspection of support might be possible through an OPTIONS request or by interacting with a defined well-known URI RFC8615 if such inspection is defined along with the field being introduced. </ins> 15.3.1. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines
Code change:
I believe that we said this could be merged when Julian's issue was addressed, which Roy's suggestion did, so merging.
Some guidance about how and if new preconditions can be defined would be helpful. See .

Related discussion:
text: 15.3.2. <del> There is no limit on the introduction of new field names, each presumably defining new semantics. New fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses. </del> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on
Code change:
NAME - is Oct 1999 correct? (taken from Last-Modified)
Last edit is 1999 but was just a markup fix, original document is dated 1996-10-03. HTH,
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.

Related discussion:
text: mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as <del> HTTP/0.9. </del> <ins> HTTP/0.9 (see HTTP09). </ins> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")
Code change:
When I was restructuring Semantics, the paragraphs for defining when a message is complete stuck out like a sore thumb. I moved them to their own section and added a comment for later definition. This issue tracks that definition (editorial).

Related discussion:
text: 5.2. <del> One of the functions of message framing is to assure that messages are . A message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the transport connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport- level error indicates that it is not complete. </del> <ins> Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. </ins> 5.3.
Code change:
We need to discuss this; prohibition at least semantically, and probably also strongly urge against accepting on the wire for security reasons (although somewhat version-specific).
Discussed; just need to align 1xx language with others.

Related discussion:
text: class of status code indicates an interim response for communicating connection status or request progress prior to completing the <del> requested action and sending a final response.  1xx responses are terminated by the end of the header section.  Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client. </del> <ins> requested action and sending a final response.  Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client. A 1xx response is terminated by the end of the header section because it cannot contain a message body or trailers. </ins> A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one.  A
Code change:
IIUC httpbis-semantics changes the field name registry, thus updating BCP 90 / RFC3684. Is that correct? Should httpbis-semantics mention that? NAME
"obsoletes": no, because BCP 90 is also for email. "updates": yes, I think so. NAME
Hm; I suppose so, given that it's taking some of 3684's turf away.
Now does that make SEMANTICS part of BCP90?
I'm inclined to say no -- it modifies the scope of BCP90 to exclude HTTP header fields. Worth discussing more broadly, though.

Related discussion:
text: 17.4. <ins> This specification updates the HTTP related aspects of the existing registration procedures for message header fields defined in RFC3864. It defines both a new registration procedure and moves HTTP field definitions into a separate registry. </ins> Please create a new registry as outlined in field-name.registry. After creating the registry, all entries in the Permanent and
Code change:
: >A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules: I'm hearing that this 60-second window is problematic for videos, where clients often request a partial video segment within a minute of it being published (thanks to e.g., CMAF). Since those requests use , they require a strong validator. Should we revisit this, given that it is an arbitrarily chosen value by our own admission? I agree that some caution is necessary here, but a one-size-fits-all approach doesn't seem viable.
Discussed on call. Sense is to make this much more based upon the judgement of the implementation, rather than just an arbitrary number.
Suggestion:
NAME NAME - this creates a nested unordered list which comes out really strangely in HTML, please check. Maybe it would be better to have the two statements (that are nested) in a single list entry.

Related discussion:
text: same Last-Modified time, then at least one of those responses would have a <del> value equal to its Last-Modified time.  The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response.  An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short. </del> <ins> value equal to its Last-Modified time. </ins> 7.9.3.
Code change:
I think this should be something like "Message Framing and Incomplete Messages", and should be after the headers / payload / trailers sections.

Related discussion:
text: 5.1. <ins> Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. 5.2. </ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message
Code change:
I think this should be something like "Message Framing and Incomplete Messages", and should be after the headers / payload / trailers sections.

Related discussion:
text: protocol within a protocol element that requires sending a minor version. <del> 5.2. Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. </del> 5.3. HTTP messages use key/value pairs to convey data about the message,
Code change:
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.

Related discussion:
text: 5.1. <ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message can change versions as it passes through intermediaries, because the semantics of a HTTP message are independent of its version. </ins> While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire
Code change:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Related discussion:
text: 3.2. <ins> Caches are required to update a stored response's header fields from another (typically newer) response in several situations; for example, see combining.responses, freshening.responses and head.effects. When doing so, the cache MUST add each header field in the provided response to the stored response, replacing field values that are already present, with the following exceptions: In some cases, caches (especially in user agents) store processed representations of the received response, rather than the response itself, and updating header fields that affect that processing can result in inconsistent behavior and security issues.  Caches in this situation MAY omit these header fields from updating stored representations on an exceptional basis, but SHOULD limit such omission to those fields necessary to assure integrity of the stored representation. For example, a browser might store a response's body after removing content-codings, thereby making its metadata inaccurate.  Updating that stored metadata with a different Content-Encoding header field would be problematic.  Likewise, a browser might store a post-parse tree representation of HTML, rather than the body received in the response; updating the Content-Type header field would not be workable in this case, because any assumptions about the format made in parsing would now be invalid. Furthermore, some fields are automatically processed and removed by the HTTP implementation; for example, the Content-Range header field. Implementations MAY automatically omit such header fields from updates, even when the processing does not actually occur. Note that the Content-* prefix is not a signal that a header field is omitted from update; it is a convention for MIME header fields, not HTTP. 3.3. </ins> If the request method is GET, the response status code is , and the entire response header section has been received, a cache
Code change:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Related discussion:
text: status code. <del> 3.3. </del> <ins> 3.4. </ins> A shared cache MUST NOT use a cached response to a request with an
Code change:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Related discussion:
text: public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). <del> 3.4. </del> <ins> 3.5. </ins> A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more