Sending a Validation Request and secondary cache keys

[mnot]

Caching says:

One or more entity-tags, indicating one or more stored responses, can be used in an If-None-Match header field for response validation, or in an If-Match or If-Range header field for representation selection (i.e., the client is referring specifically to one or more previously obtained representations with the listed entity-tags).

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.

[mnot]

I think it needs to constrain it to the selected stored responses.

[royfielding]

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.

[mnot]

4.3.1. Sending a Validation Request

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]

[royfielding]

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?

[mnot]

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.