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

The "Vary: accept-encoding" header is not always set #3292

Closed
kanongil opened this issue Aug 17, 2016 · 2 comments
Closed

The "Vary: accept-encoding" header is not always set #3292

kanongil opened this issue Aug 17, 2016 · 2 comments
Assignees
Labels
Milestone

Comments

@kanongil
Copy link
Contributor

@kanongil kanongil commented Aug 17, 2016

When hapi only sometimes sets the vary header, based on input headers, it can cause caching issues.

I noticed that this is done for the accept-encoding header here:

hapi/lib/transmit.js

Lines 207 to 209 in 26aaff3

if (request.headers['accept-encoding']) {
response.vary('accept-encoding');
}
.

If a caching agent receives this response to a request without the accept-encoding header, it won't know to re-fetch the resource when another requests is made with the header, thus returning an incorrect response to the client.

The simple fix is to remove the if. Ideally it should only include the vary header for routes that serves different responses depending on the accept-encoding header. Maybe some kind of switch is needed?

@hueniverse hueniverse added the bug label Aug 23, 2016
@hueniverse hueniverse added this to the 15.0.0 milestone Aug 23, 2016
@hueniverse hueniverse self-assigned this Aug 23, 2016
@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Aug 23, 2016

If you have ideas how to do this better than just always set it, lmk.

@kanongil
Copy link
Contributor Author

@kanongil kanongil commented Aug 23, 2016

Of the top of my head, the response is only changed based of that header for compressible responses, where compression has not been disabled. Eg. request.connection.settings.compression && mime.compressible.

@hueniverse hueniverse reopened this Aug 23, 2016
hueniverse added a commit that referenced this issue Aug 26, 2016
@hueniverse hueniverse closed this Aug 26, 2016
@lock lock bot locked as resolved and limited conversation to collaborators Jan 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants