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

RFC7234#section-7.1.4 conformance #4846

Open
aodhol opened this issue Nov 26, 2023 · 0 comments
Open

RFC7234#section-7.1.4 conformance #4846

aodhol opened this issue Nov 26, 2023 · 0 comments

Comments

@aodhol
Copy link

aodhol commented Nov 26, 2023

The implementation returns nil upon seeing the Vary header but is that what the standard implies? Shouldn't the cache keys be expanded instead?

// Vary: https://tools.ietf.org/html/rfc7231#section-7.1.4
/* "1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same
values for the listed fields as the original request (Section 4.1
of [RFC7234]). In other words, Vary expands the cache key
required to match a new request to the stored cache entry."
If we do not store this response, we will never use it to satisfy a later request, including a later request for which it would be incorrect.
*/
if httpResponse.allHeaderFields["Vary"] != nil {
return false
}

A use case here might be Vary: Accept-Language to allow responses for different languages to be cached separately so if a user changes languages in a mobile-App for example, a response in the wrong language wouldn't be returned to them / the right response would be returned to them if it had been cached for the cache keys derived from the header...

@aodhol aodhol changed the title RFC conformance RFC7234#section-7.1.4 conformance Nov 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant