New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending a Validation Request and secondary cache keys #110

Closed
mnot opened this Issue Jun 29, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@mnot
Copy link
Member

mnot commented Jun 29, 2018

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 mnot added the caching label Jun 29, 2018

@mnot

This comment has been minimized.

Copy link
Member Author

mnot commented Jun 29, 2018

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

@royfielding

This comment has been minimized.

Copy link
Member

royfielding commented Jun 30, 2018

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

This comment has been minimized.

Copy link
Member Author

mnot commented Oct 10, 2018

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]

@mnot mnot added the has-proposal label Oct 10, 2018

@royfielding

This comment has been minimized.

Copy link
Member

royfielding commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Member Author

mnot commented Oct 11, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment