Vary Header should not be controlled by the client #138
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Vary header is a way for servers to control caching mechanisms, and it is purely a server-side mechanism. The client does not control or affect the Vary header. Issue #136 introduced logic that does not conform to this: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-12.5.5
There are several approaches we can take with the Vary header:
Vary: X-Inertia
header.Vary
header if it wasn't set before, which is the default logic used in Rails: https://github.com/rails/rails/blob/b8720e7cb8c9894d142b8576c21065c92cd1907a/actionpack/lib/action_controller/metal/rendering.rb#L220-L224X-Inertia
if theVary
header was set previously, or set theVary: X-Inertia
header if it was not.I believe the third option makes the most sense: it allows users to add other headers, like
Accept-Language
, to theVary
list, but it also prevents them from omittingX-Inertia
.