If-Modified-Since vs. If-None-Match

The usual browser conditional request looks like this:

GET /i/yahoo.gif

HTTP/1.1 Host: us.yimg.com

If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT

If-None-Match: "10c24bc-4ab-457e1c1f" HTTP/1.1

But what is the relation between If-Modified-Since and If-None-Match. OR? AND? So if any of them "fails", a new version will be sent?

Solution 1:

http://www.ietf.org/rfc/rfc2616.txt

13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates

• An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header field) as cache validators, MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request.

• An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity tags as cache validators, MUST NOT return a locally cached response to the client unless that cached response is consistent with all of the conditional header fields in the request.

  • Note: The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative assumptions about the validators they receive.

Solution 2:

Note that the newer "RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" has a section on precedence which changes how this behaviour is specified. This effectively says that If-None-Match takes precedence over If-Modified-Since. See:

   3.  When If-None-Match is present, evaluate the If-None-Match
       precondition:

       *  if true, continue to step 5

       *  if false for GET/HEAD, respond 304 (Not Modified)

       *  if false for other methods, respond 412 (Precondition Failed)

   4.  When the method is GET or HEAD, If-None-Match is not present, and
       If-Modified-Since is present, evaluate the If-Modified-Since
       precondition:

       *  if true, continue to step 5

       *  if false, respond 304 (Not Modified)

   5.  When the method is GET and both Range and If-Range are present,
       evaluate the If-Range precondition:

       *  if the validator matches and the Range specification is
          applicable to the selected representation, respond 206
          (Partial Content) [RFC7233]

   6.  Otherwise,

       *  all conditions are met, so perform the requested action and
          respond according to its success or failure.

See here how step 3. causes an evaluation of the If-None-Match pre-condition, and if it is present then you never go to step 4. which is the step that evaluates If-Modified-Since.