jiebi/CodeConvo huggingface dataset:
Code change:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Related discussion:
text: If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client has already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method.
Code change:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Related discussion:
text: To evaluate a received If-Match header field: An origin server MUST NOT perform the requested method if a received <del> If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del> <ins> If-Match condition evaluates to false.  Instead, the origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  For example, multiple user agents writing to a common resource as a semaphore (e.g., a non-atomic increment) are likely to collide and potentially lose important state transitions.  For those kinds of resources, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method.  In other cases, excluding the ETag field from a success response might encourage the user agent to perform a GET as its next request to eliminate confusion about the resource's current state. </ins> The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
Code change:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Related discussion:
text: . A recipient MUST ignore the If-Unmodified-Since header field if the <del> received field value is not a valid HTTP-date, or if the field value has more than one member. </del> <ins> received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.
Code change:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Related discussion:
text: (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition as per evaluation prior to performing the
Code change:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Related discussion:
text: If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the <del> origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del> <ins> origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  In those cases, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method. </ins> The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
Code change:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Related discussion:
text: . <ins> A field present in a 206 response indicates the number of octets in the body of this message, which is usually not the complete length of the selected representation.  Each field includes information about the selected representation's complete length. </ins> If a 206 is generated in response to a request with an header field, the sender SHOULD NOT generate other representation
Code change:
reads: This seems to have the effect that 412 cannot happen as part of a 100-continue response, but instead, the entire upload body must be parsed for errors (such as ), and only if it is free of errors can the server return 412 (Precondition Failed). This seems unnecessary and wasteful of bandwidth, and perhaps a result of the fact that server-side validation of documents, including the 422 Unprocessable Entity status code, is a comparatively newer feature of HTTP servers. [1] If this is the case, consider relaxing this requirement so that 412 (Precondition Failed) is the last error tested before the request body is parsed. [1] See mailing list thread:

Related discussion:
text: Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully <del> performed its normal request checks and just before it would perform the action associated with the request method.  A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a </del> <ins> performed its normal request checks and just before it would process the request body (if any) or perform the action associated with the request method.  A server MUST ignore all received preconditions if its response to the same request without those conditions, prior to processing the request body, would have been a status code other than a </ins> or <del> .  In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests. </del> <ins> .  In other words, redirects and failures that can be detected before significant processing occurs take precedence over the evaluation of preconditions. </ins> A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT
Code change:
Need to talk about the on-the-wire scenarios; representation w/ vary vs without.
When making the edit above, I started to wonder what the best strategy was to recommend: Use the most recent valid Vary field value (current text) Just give the one without a Vary field value the lowest priority Thoughts NAME NAME ?
This language is a bit ambiguous regarding whether the received response is included in those considered, etc.
On second reading this wasn't as bad as I thought; made a few small editorial clarifications.

Related discussion:
text: doing so (e.g., qvalues on and similar request header fields), that mechanism MAY be used to <del> select preferred responses; of the remainder, the most recent response (as determined by the </del> <ins> select a preferred response.  If such a mechanism is not available, or leads to equally preferred responses, the most recent response (as determined by the </ins> header field) is used, as per constructing.responses.from.caches. <del> Note that in practice, some resources might send the Vary header field on responses inconsistently.  When a cache has multiple responses for a target URI, and one or more omits the Vary header field, it SHOULD use the most recent non-empty value available to select an appropriate response for the request. </del> <ins> Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), selecting it for requests to that resource even when more preferable responses are available.  When a cache has multiple responses for a target URI and one or more omits the Vary header field, it SHOULD use the most recent (see age.calculations) valid Vary field value available to select an appropriate response for the request. </ins> If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server
Code change:
: I think that MAY should be prose, and should also list retrying the request as an option.

Related discussion:
text: 3.1. <del> Caches MUST include all received header fields -- including </del> <ins> Caches MUST include all received response header fields -- including </ins> unrecognised ones -- when storing a response; this assures that new HTTP header fields can be successfully deployed.  However, the following exceptions are made:
Code change:
: I think that MAY should be prose, and should also list retrying the request as an option.

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:
: I think that MAY should be prose, and should also list retrying the request as an option.

Related discussion:
text: according to the calculations in expiration.model. A cache MUST NOT generate a stale response if it is prohibited by an <del> explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an </del> <ins> explicit in-protocol directive (e.g., by a "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an </ins> applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive).
Code change:
: I think that MAY should be prose, and should also list retrying the request as an option.

Related discussion:
text: intervening caches are required to invalidate stored responses to keep their contents up to date. <del> means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through. </del> A cache MUST invalidate the target URI (target.resource) and the URI(s) in the
Code change:
: I think that MAY should be prose, and should also list retrying the request as an option.

Related discussion:
text: receives a non-error response to a request with a method whose safety is unknown. <del> Here, a "non-error response" is one with a </del> <ins> means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. A "non-error response" is one with a </ins> or status code. <ins> Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through. </ins> 5. This section defines the syntax and semantics of HTTP fields related
Code change:
: I think that MAY should be prose, and should also list retrying the request as an option.

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 think that MAY should be prose, and should also list retrying the request as an option.

Related discussion:
text: Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the <del> field names listed in the two tables of header.field.definitions. </del> <ins> field names listed in the table in header.field.definitions. </ins> 8.2.
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: 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:
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: its payload, the target resource, or the connection.  They are called "HTTP fields" or just " <del> ". </del> <ins> ".  Fields occur in groups called " " or just "sections". </ins> Fields that are sent/received before the message body are referred to as "header fields" (or just "headers", colloquially) and are located
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: authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. <del> A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma and </del> <ins> A recipient MAY combine multiple field lines within a field section that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma and </ins> (optional whitespace).  For consistency, use comma SP.
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: Obsolete formats: <del> HTTP-date is case sensitive.  A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar.  The semantics of </del> <ins> HTTP-date is case sensitive.  Note that Caching relaxes this for cache recipients. A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar.  The semantics of </ins> ,
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: After that is complete, please update the new registry with the field names listed in the following table. <del> Furthermore, the field name "*" is reserved, since using that name as an HTTP header field might conflict with its special semantics in the </del> <ins> The field name "*" is reserved, since using that name as an HTTP header field might conflict with its special semantics in the </ins> header field (field.vary).