ETags behind gateway that compresses responses

[kanongil]

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]

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