Skip to content
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

Describe Vary operation more clearly #28

Closed
mnot opened this issue Jun 20, 2017 · 5 comments
Closed

Describe Vary operation more clearly #28

mnot opened this issue Jun 20, 2017 · 5 comments
Assignees
Labels

Comments

@mnot
Copy link
Member

@mnot mnot commented Jun 20, 2017

This confuses many people.

@mnot mnot added the caching label Jun 20, 2017
@mnot mnot self-assigned this Jun 29, 2018
@mnot
Copy link
Member Author

@mnot mnot commented Oct 9, 2018

Currently:

2. Overview of Cache Operation

The primary cache key consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.

If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated by a secondary key for the values of the original request's selecting header fields (Section 4.1).

... but the cache key terms aren't used anywhere else except 4.3.4. It would be good to use this consistently in 3, 4 and especially 4.1.

@mnot
Copy link
Member Author

@mnot mnot commented Oct 9, 2018

OTOH, since POST can be reused for GET, the definition of "cache key" is misleading. Perhaps the best thing to do would be to remove these terms completely.

@mnot
Copy link
Member Author

@mnot mnot commented Oct 9, 2018

It would also be good to note that in practice, some implementations "flap" between having Vary and none; this should be clarified and mitigated.

@wsargent
Copy link

@wsargent wsargent commented Dec 24, 2018

The thing that's always confused me about the spec is not even "cache key" but "secondary cache key." I understand what the spec is getting at, but it's very odd to have a cache which returns two different entries:

val singleEntry: Response = cache(key)

or if there's a value entry:

val multipleEntries: Map[SecondaryKey, Response) = cache(key)

@mnot
Copy link
Member Author

@mnot mnot commented Feb 3, 2020

I think this has improved enough to close the issue; if anyone has a suggestion for further improvement, please comment.

@mnot mnot closed this Feb 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants