jiebi/CodeConvo huggingface dataset:
Code change:
There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.

Related discussion:
text: The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del> <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.
Code change:
There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.

Related discussion:
text: obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: representation. For example, a browser might decode the content coding of a response <del> payload while it is being received, creating a disconnect between the data it has stored and the response payload's original metadata. Updating that stored metadata with a different </del> <ins> while it is being received, creating a disconnect between the data it has stored and the response's original metadata.  Updating that stored metadata with a different </ins> header field would be problematic.  Likewise, a browser might store a <del> post-parse tree representation of HTML, rather than the payload </del> <ins> post-parse tree representation of HTML, rather than the content </ins> received in the response; updating the header field would not be workable in this case, because any
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: A response's age can be calculated in two entirely independent ways: <del> These are combined as </del> <ins> The corrected_age_value MAY be used as the corrected_initial_age.  In circumstances where very old cache implementations that might not correctly insert </ins> <del> unless the cache is confident in the value of the header field (e.g., because there are no HTTP/1.0 hops in the header field), in which case the corrected_age_value MAY be used as the corrected_initial_age. </del> <ins> are present, corrected_initial_age can be calculated more conservatively as </ins> The current_age of a stored response can then be calculated by adding the time (in seconds) since the stored response was last validated by
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on <del> the received precondition header fields and their precedence, as defined in precedence.  The </del> <ins> the received precondition header fields and their precedence.  In summary, the </ins> and <del> conditional header fields are not applicable to a cache. </del> <ins> conditional header fields are not applicable to a cache, and takes precedence over . See precedence for a complete specification of precondition precedence. </ins> A request containing an
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: 4.3.5. A response to the HEAD method is identical to what an equivalent <del> request made with a GET would have been, except it lacks payload data.  This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the payload data is not desired even if it has changed. </del> <ins> request made with a GET would have been, without sending the content. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the content is not desired even if it has changed. </ins> When a cache makes an inbound HEAD request for a target URI and receives a
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was <del> contacted, since the response might have been received from an HTTP/1.0 cache that does not implement Age. </del> <ins> contacted. </ins> 5.2.
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: 5.2.1.6. The "no-transform" request directive indicates that the client is <del> asking for intermediaries to avoid transforming the payload, as </del> <ins> asking for intermediaries to avoid transforming the content, as </ins> defined in message.transformations. 5.2.1.7.
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del> <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the <del> payload, as defined in message.transformations. </del> <ins> content, as defined in message.transformations. </ins> 5.2.2.6.
Code change:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Related discussion:
text: 7.1. Various attacks might be amplified by being stored in a shared cache. <del> Such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </del> <ins> Such "cache poisoning" attacks use the cache to distribute malicious content to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </ins> One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see
Code change:
It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).

Related discussion:
text: The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del> <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.
Code change:
It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).

Related discussion:
text: obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary
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: 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:
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: A conditional request is an HTTP request with one or more request header fields that indicate a precondition to be tested before applying the request method to the target resource.  evaluation <del> defines when preconditions are applied.  precedence defines the order of evaluation when more than one precondition is present. </del> <ins> defines when to evaluate preconditions and their order of precedence when more than one precondition is present. </ins> Conditional GET requests are the most efficient mechanism for HTTP cache updates Caching.  Conditionals can also be applied to state-
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: To evaluate a received If-None-Match header field: <del> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the </del> <ins> An origin server MUST NOT perform the requested method if a received If-None-Match condition evaluates to false; instead, the origin server MUST respond with either a) the </ins> status code if the request method is GET or HEAD or b) the