jiebi/CodeConvo huggingface dataset:
Code change:
They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)

Related discussion:
text: representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation. <ins> A valid can be distinguished from a valid by examining the first three characters for a DQUOTE. </ins> A client MUST NOT generate an If-Range header field in a request that does not contain a
Code change:
They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)

Related discussion:
text: 13.2. <ins> 13.2.1. </ins> Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully performed its normal request checks and just before it would process
Code change:
They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)

Related discussion:
text: response. <del> 13.3. </del> <ins> 13.2.2. </ins> When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes
Code change:
Those changes are editorial.
specifies what to do when it isn't present (use the received time), but not what to do when it doesn't parse. The intuitive thing to do is align, and say that the received time should be used in this situation as well -- but probably not require implementations to replace it if forwarded. I might write some tests...
Okay, I am still waiting on those new glasses. Too much Age. It's fine with me if we interpret an invalid Date as the received time, but that assumes we know the received time when we parse the Date. I think as long as the scope is specific to Caching, we should specify that a cache always record the time received (regardless of Date) and use the received time if the Date field value is invalid.
is used in a number of places in caching, so that modification will be pretty invasive. Why do you think it needs to be restrained to just caching? I suppose it could be specified in semantics as something like 'If the Date field value does not parse, it MAY be replaced with the time the message was received. Caches SHOULD consider the message receipt time as the Date value when it cannot be parsed.'
The "it" in that last sentence has an unclear subject (is it the date, the arrival time, or the cache?), and "consider" -> "use".
The only reason I said it is okay for caching is because we already depend on the cache having a clock and storing time received. It seems reasonable, regardless of role, if the recipient has a clock. But I wasn't suggesting a new requirement.

Related discussion:
text: corresponding Date header field to the message's header section if it is cached or forwarded downstream. <ins> A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. </ins> A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP
Code change:
Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.

Related discussion:
text: the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable <del> whitelist of safe request targets. </del> <ins> list of safe request targets. </ins> A server MUST NOT send any
Code change:
Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.

Related discussion:
text: might be strongly correlated to membership in a particular ethnic group.  An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites <del> that have been whitelisted, perhaps via interaction after detecting a </del> <ins> that have been explicitly permitted, perhaps via interaction after detecting a </ins> header field that indicates language negotiation might be useful.
Code change:
This isn't a place for equivocation. This could have been MUST except that that isn't good to use here. I considered just "conforms to" as well. That would also work, but that is incompatible with "wishes to" and I was less confident in removing that. I could do "conforms to" with "gateway that interoperates with inbound HTTP servers", but that's a bigger change.

Related discussion:
text: inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with <del> third-party HTTP servers ought to conform to user agent requirements </del> <ins> third-party HTTP servers needs to conform to user agent requirements </ins> on the gateway's inbound connection. A
Code change:
In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.

Related discussion:
text: specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with <del> that server has been protected for confidentiality and integrity through the use of strong encryption. </del> <ins> that server has confidentiality and integrity protection that is acceptable to both client and server. </ins> The origin server for an "https" URI is identified by the
Code change:
In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.

Related discussion:
text: A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts <del> secured responses to those requests. </del> <ins> secured responses to those requests.  Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time. </ins> Resources made available via the "https" scheme have no shared identity with the "http" scheme.  They are distinct origins with
Code change:
I know that this is pretty obvious and implied, but maybe it's worth saying.
maybe just s/TE header field/TE request header field/?

Related discussion:
text: how trailer field values can be safely merged. The presence of the keyword "trailers" in the TE header field <del> (field.te) indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients.  For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients. </del> <ins> (field.te) of a request indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients.  For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients. </ins> Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes
Code change:
Though I think that this text is correct, an HTTP/3 response only ends when the stream is closed, not at the end of the header section. I think that it's not necessary to say this bit anyway.
The related parts were done in so this bit can be applied now as editorial.

Related discussion:
text: 9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send content in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about </del> <ins> send content in the response.  HEAD is used to obtain metadata about </ins> the without transferring its representation data, often for the sake of
Code change:
The original text here sort of implied that it was enough for an origin server to just send 2xx. That assumed that the request was for the origin server itself and elided a bunch of detail. This is shorter and clearer, I think.
I didn't intend anything here other than a clarification of what was written. I'm mostly guessing what was intended as I don't know what the original text truly intended to say. (I think that it was always possible to use CONNECT with a target of the origin server to do URL But I didn't want to highlight that here; it's a little bit of an odd thing to decide to do and so I wouldn't want to encourage it.)

Related discussion:
text: mapping its semantics into the protocol's wire format. CONNECT is intended only for use in requests to a proxy.  An origin <del> server that receives a CONNECT request for itself MAY respond with a status code to indicate that a connection is established.  However, most origin servers do not implement CONNECT. </del> <ins> server MAY accept a CONNECT request, but most origin servers do not implement CONNECT. </ins> The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another
Code change:
The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.

Related discussion:
text: 5.6.2. <ins> Tokens are short textual identifiers that do not include whitespace or delimiters. </ins> Many HTTP field values are defined using common syntax components, separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not
Code change:
The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.

Related discussion:
text: (DQUOTE and "(),/:;<=>?@[\]{}"). <del> Tokens are short textual identifiers that do not include whitespace or delimiters. </del> 5.6.3. This specification uses three rules to denote the use of linear
Code change:
In : This is probably overly broad considering that the ABNF says (I question the wisdom of including HTAB, but now is not the time to worry about that). Could this be changed to "printable or visible US-ASCII octets, plus SP and HTAB"? (Incidentally, why doesn't the rule use the ABNF rule?)

Related discussion:
text: charset ISO-8859-1, supporting other charsets only through use of RFC2047 encoding.  In practice, most HTTP field values use only a subset of the US-ASCII charset USASCII.  Newly defined fields SHOULD <del> limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data. </del> <ins> limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other octets in field content (obs-text) as opaque data. </ins> Field values containing control (
Code change:
…levant when some of the acceptable ones are redundant (
However, from item 4 implies otherwise. I think that this only applies if the server wishes to choose between codings, as opposed to apply them all. Compression codings are usually mutually exclusive, but other codings are not necessarily. Splitting this point into a paragraph might be the way to resolve this:
See also URL

Related discussion:
text: A server tests whether a content-coding for a given representation is acceptable using these rules: <ins> A representation could be encoded with multiple content codings. However, most content codings are alternative ways to accomplish the same purpose (e.g., data compression).  When selecting between multiple content codings that have the same purpose, the acceptable content coding with the highest non-zero qvalue is preferred. </ins> An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content-coding in response.  If an Accept-Encoding header field is present in a request
Code change:
I wasn't sure where exactly to include the citation, but the end of the sentence seemed harmless.

Related discussion:
text: The status code indicates that one or more conditions given in the <del> request header fields evaluated to false when tested on the server. This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. </del> <ins> request header fields evaluated to false when tested on the server (conditional.requests).  This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. </ins> 15.5.14.
Code change:
The section was talking about server load as well, but it doesn't mention that being a cost of closing connections.
I thought that the assumption was OK-ish: the expectation that clients will retry. That said, I agree that this entire thing could be better. I was looking for a minimal fix.

Related discussion:
text: allow the underlying transport's flow-control mechanisms to resolve temporary overloads, rather than terminate connections with the expectation that clients will retry.  The latter technique can <del> exacerbate network congestion. </del> <ins> exacerbate network congestion or server load. </ins> A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request.  If the
Code change:
draft-ietf-httpbis-semantics says in the intro: the multipart/byteranges media type. Is this truly something specific to 1.1? Are there difference in other versions?
Good catch.
okay (editorial)

Related discussion:
text: " (content.negotiation). <del> This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. </del> <ins> This document defines HTTP range requests, partial responses, and the multipart/byteranges media type. </ins> This document obsoletes the portions of RFC7230 that are independent of the HTTP/1.1 messaging syntax and connection management, with the