Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Behavior of checkNotModified(String etag, long lastModifiedTimestamp) does not match HTTP recommendations [SPR-14224] #18798
According to RFC2616 https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html if a request has the If-None-Match or If-Modified-Since headers are set on a request (that is, either one or the other, but not both), a 304 Not Modified can be returned if the the ETag matches or the resource is has not been modified since the specified date.
According to the same specification, if both headers are set, the behavior of the server is undefined. In other words, a client should never use both, as it does not make sense (the server could return "418 I'm a teapot" if it felt like it).
Thus for the checkNotModified(String etag, long lastModifiedTimestamp) method to be useful, it should:
However, currently the implementation of the method returns false unless both headers are present (a case which should never happen). Thus effectively it always returns false.
Referenced from: commits a50ea80
Brian Clozel commented
It seems the latest version of this RFC7232 states otherwise:
see Section 2.4
Also, the same RFC precisely describes how origin servers should react to multiple conditional headers in Section 6, "Precedence".
Let me know if you think that the current behavior does not match the latest spec.
Sebastiaan van Erk commented
It seems that RFC7232 does indeed seem to override RFC2616 in terms of the behavior when multiple preconditions are present. However, the Precedence section seems be exactly in accordance with the behavior I sketched above, and not with the current implementation. That is:
In other words, if one of the two is present, use that header; if both are present the If-None-Match takes precedence.