jiebi/CodeConvo huggingface dataset:
Code change:
The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.

Related discussion:
text: The "no-cache" response directive indicates that the response MUST <del> NOT be used to satisfy a subsequent request without successful validation on the origin server.  This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </del> <ins> NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </ins> If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request,
Code change:
The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.

Related discussion:
text: 5.2.2.3. The "no-store" response directive indicates that a cache MUST NOT <del> store any part of either the immediate request or response.  This directive applies to both private and shared caches.  "MUST NOT </del> <ins> store any part of either the immediate request or response, and MUST NOT use the response to satisfy any other request. This directive applies to both private and shared caches.  "MUST NOT </ins> store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as
Code change:
seems like it should be in messaging.
Part of it needs to be in messaging (how to do it per version), while a shorter description needs to be here just to point out that it is version dependent. The semantics don't make any sense otherwise.
Ack. Will take a stab at it.
The caching document should clarify that only final responses are cached.
Works for me.

Related discussion:
text: The request method is understood by the cache and defined as being cacheable, and <ins> the response status code is final (see associating.response.to.request), and </ins> the response status code is understood by the cache, and the "no-store" cache directive (see header.cache-control) does not
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST: </del> <ins> cache MUST use the header fields provided in the new response, aside from </ins> <del> delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, use other header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del> <ins> , to replace all instances of the corresponding header fields in the stored response. </ins> 4.
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: interval since that time.  A typical setting of this fraction might be 10%. <del> When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a header field with a 113 warn-code (see warn.113) in the response if its current_age is more than 24 hours and such a warning is not already present. </del> 4.2.3. The
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). <del> A cache SHOULD generate a header field with the 110 warn-code (see warn.110) in stale responses.  Likewise, a cache SHOULD generate a 112 warn-code (see warn.112) in stale responses if the cache is disconnected. A cache SHOULD NOT generate a new header field when forwarding a response that does not have an header field, even if the response is already stale.  A cache need not validate a response that merely became stale in transit. </del> 4.3. When a cache has one or more stored responses for a requested URI,
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: response also lacks a validator, then that stored response is identified for update. <del> For each stored response identified for update, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, </del> <ins> For each stored response identified for update, the cache MUST use the header fields provided in the </ins> <del> use other header fields provided in the response to replace all instances of the corresponding header fields in the stored response. </del> <ins> response to replace all instances of the corresponding header fields in the stored response. </ins> 4.3.5.
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: consider the stored response to be stale. If a cache updates a stored response with the metadata provided in a <del> HEAD response, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any </del> <ins> HEAD response, the cache MUST use the header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the </ins> <del> header fields in the stored response with warn-code 2xx; and, use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del> <ins> header field. </ins> 4.4.
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: 8.3. <del> Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> with the registration procedure of warn.code.registry and the warn code values summarized in the table of header.warning. </del> <ins> Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> to the effect that Warning is obsoleted. </ins> Index <del> 1 110 (warn-code) 111 (warn-code) 112 (warn-code) 113 (warn-code) 199 (warn-code) 2 214 (warn-code) 299 (warn-code) </del> A Age header field age
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: cache entry cache key <del> D Disconnected Operation (warn-text) </del> E Expires header field explicit expiration time
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: VCHAR H <del> Heuristic Expiration (warn-text) </del> heuristic expiration time M <del> Miscellaneous Persistent Warning (warn-text) Miscellaneous Warning (warn-text) </del> max-age (cache directive) max-stale (cache directive) min-fresh (cache directive)
Code change:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Related discussion:
text: proxy-revalidate (cache directive) public (cache directive) <del> R Response is Stale (warn-text) Revalidation Failed (warn-text) </del> S s-maxage (cache directive) shared cache stale strong validator <del> T Transformation Applied (warn-text) </del> V validator
Code change:
Sounds good to me.
Might want to mention the scope of applicability for HTTP caching a bit more carefully, esp. with respect to other caches (esp. in browsers).
I think the best thing to do might be to change to something like "Relationship to Other Caches and History Lists" and expand accordingly.
Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation retrieved earlier in a session. Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: no-store).

Related discussion:
text: 6. <del> User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation </del> <ins> Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation </ins> retrieved earlier in a session. <del> The freshness model (expiration.model) does not necessarily apply to history mechanisms.  That is, a history mechanism can display a previous representation even if it has expired. </del> <ins> Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. </ins> <del> This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store). </del> <ins> The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache- Control: no-store). </ins> 7.
Code change:
Caching : Can the cache send any old entity-tag it has stored for the URL in these headers, or must it only do it for those that can be selected by the incoming request, as per the secondary cache key algorithm? Also, this section uses "selected" in a different meaning; that should probably be changed to avoid confusion.
I think it needs to constrain it to the selected stored responses.
We need to be careful to include the case where an upstream cache (or UA) has sent a conditional request (perhaps with some of its own stored etags) and this cache is forwarding them along.
When sending a conditional request for validation, a cache updates the request it is attempting to satisfy with one or more precondition header fields. These contain validator metadata sourced from the stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. [rest as before]
Isn't this presuming the validation is part of an upstream request? What if the cache is auto-refreshing stored responses during idle time? Maybe we should define these as separate cases?
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key [ref]. It then updates that request with one or more precondition header fields. These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource.

Related discussion:
text: 4.3.1. <del> When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent to a current representation of the resource. </del> <ins> When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key caching.negotiated.responses. It then updates that request with one or more precondition header fields.  These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. </ins> One such validator is the timestamp given in a