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

ETags behind gateway that compresses responses #3956

Closed
kanongil opened this issue Jun 17, 2019 · 1 comment

Comments

@kanongil
Copy link
Member

commented Jun 17, 2019

I encountered an issue with the ETag validation for if-none-match requests that are behind an nginx gateway.

The issue

When a Hapi server sits behind an nginx reverse proxy, with compression enabled, responses that contain an ETag are returned weak. Eg. etag: "hi" is received as etag: W/"hi". This means that later conditional requests will check against the weak version: if-none-match: W/"hi", and thus never matches.

Fixes

While this is probably an nginx issue, I put it here, as Hapi might want to workaround this behaviour. This can be done by matching weak etags against non-weak etags, and taking care to return the weak ETag in the response (otherwise the client would receive 304 response with what looks like a "new" etag, since nginx does not try to gzip a 304 response).

Alternatively, I guess api could add a "weak" option on routes, to force a weak response, making the check work.

See https://stackoverflow.com/a/55525109/248062 for some more background.

@kanongil

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

I should probably add that I remove the Accept-Encoding header in the proxied requests to force nginx to do the compression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.