Closed shepmaster closed 8 years ago
That seems correct by the spec: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25
That seems correct by the spec
@TheNeikos could you clarify what "that" is in your sentence? You could mean "caching should rarely work" is correct, or "ignoring nanoseconds" is correct.
We could switch to ETags to preserve nanosecond precision. However, your fix is correct (I assume there is no way to represent nanoseconds in HTTP dates).
@TheNeikos could you clarify what "that" is in your sentence? You could mean "caching should rarely work" is correct, or "ignoring nanoseconds" is correct.
The latter of course
@shepmaster That change LGTM please feel free to make a PR. I'll merge it when the tests pass. :)
@Hoverbear uhh, didn't you already merge it? My bad for not linking to this issue though! 😇
LOL. You're right!
Debugging why my caching wasn't caching, I printed out these values:
Looking at the code:
But the HTTP header will never have nanosecond precision (
If-Modified-Since:Mon, 27 Jun 2016 16:31:32 GMT
), so the comparison will fail unless the nanosecond field happens to be zero.My local fix is to change the code to
Does that feel like the right solution? I'd be happy to submit a PR to that end.