-
Notifications
You must be signed in to change notification settings - Fork 12
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
Response Variants #60
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An HTTP response can nominate a set of headers pertaining to the initiating request, using the Vary header, to be matched against by the incoming request before being served by caches. This makes it possible to have multiple responses per URI (e.g. one for
Accept-Encoding: gzip
and another forAccept-Encoding: brotli
for aVary: Accept-Encoding
). The prospect of implementing this seems nice due to the hypothetical increase in hit rates (the current behavior is to only keep the latest response). However, this makes it tricky to handle some cases like entry locking (lock edits on the entry scope or response scope?) & response updates (knowing which response to update).A major part of this is re-specifying the Store API to act more like a
Map<String, List<Entry>>
. Let's prioritize #50 to have a better idea of the implementation concerns of such a change.The text was updated successfully, but these errors were encountered: