Background:
nginx generates weak etags when Accept-Encoding: gzip is sent by the client
https://twitter.com/samsaffron/status/486387129165942784
I'm using restangular to make calls to the endpoints
Restangular receives a weak etag and send it in if-None-Match header without any modification to the etag
https://github.com/mgonto/restangular/blob/d55c4392b184e659c11f50e225d64c3a04da6572/src/restangular.js#L588
But nginx wouldn't match the etag with what it receives in if-None-Match,
it will send a 200 OK http response, while it should send send 304 Not Modified http response.
Postman:
If I send the etag as a strong etag in if-None-Match header (strip W/ ), nginx would send 304 response.
Postman:
How to fix this?
Should restangular strip the W/ from the etag when it sends it as if-None-Match?
MDN says that W/ is not necessary to be sent in if-None-Match
may be prefixed by `W/` to indicate that the weak comparison algorithm should be used (This is useless with If-None-Match as it only uses that algorithm).
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match
Or should nginx be able to match it even if it is a weak etag?
nginx version 1.13.3
I had the same problem, with getting a 200 OK (and body) from nginx when sending back the weak etag in If-None-Match that it just sent me! Weak etag support was added in nginx 1.7.3, so it should work.
The issue (after much head scratching) turned out to be a local OS cache (used by macOS's NSURLConnection) that was substituting the 200 OK for the 304 Not Modified. Checking the nginx logs showed that it was actually responding with 304, and not sending any body, as it should.
This might not have been your problem, but this SO question was the one that matched my search, so I'm leaving this answer here in case it helps others treading the same path later :)