HTTP If-None-Match vs. If-Match
caching, header, http, http-1.1, http-headers
Solution
If-Match
The server MUST return a 412 (Precondition Failed) response, if:
- none of the entity tags match,
- or "*" is given and no current entity exists
If-Match should be ignored, if:
- any of the entity tags match
- or if the request results in anything other than a 2xx or 412 status (without If-Match)
- or if "*" is given and any current entity exists for the resource
Conclusion on if-match:
- The meaning of "If-Match: *" is that the method should be performed if the representation selected by the origin server ... exists, and must not be performed if the representation does not exist.
If-Match in RFC2616
If-Unmodified-Since
The server MUST return a 412 (Precondition Failed) response, if:
- the requested variant has been modified since the specified time
If-Unmodified-Since should be ignored, if
- the requested resource has not been modified since the time specified in this field
- or the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status
- or the specified date is invalid
If-Unmodified-Since in RFC2616
If-Range
Informally, its meaning is 'if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'
Preconditions:
- The `If-Range` header SHOULD only be used together with a `Range` header, and MUST be ignored if the request does not include a `Range` header, or if the server does not support the sub-range operation.
Server SHOULD provide 206 (Partial content) response, if `If-Range` header matches the current entity tag for the entity. Otherwise, server SHOULD return the entire entity using a 200 (OK) response.
If-Range in RFC2616
Undefined results
Having the following combination of headers leads to an undefined result:
- If-Modified-Since and If-Match
- If-Modified-Since and If-Unmodified-Since
- If-None-Match and If-Match
- If-None-Match and If-Unmodified-Since
These rules have been decomposed from the following ones (can be found in RFC2616):
- If-Match and ( If-None-Match or If-Modified-Since )
- If-Modified-Since and ( If-Match or If-Unmodified-Since )
- If-None-Match and ( If-Match or If-Unmodified-Since )
- If-Unmodified-Since and ( If-None-Match or If-Modified-Since )
A more recent RFC 7232 superseded 2616.
Problem
I'm currently building up a PHP script that will answer HTTP "304 Not Modified" when required. (See question #2086712 for what I do so far). Currently I answer to the following: - If-Modified-Since - If-None-Match But I found out that 3 more headers can trigger a "conditional GET" (See http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3): - If-Match - If-Unmodified-Since - If-Range The last 2 seems irrevelent to my caching system (they seem to be used when resuming "big" downloads) but I haven't found if "If-Match" could be of use in my system. Does "If-Match" is used in proxies or Web browser for "regular" page content? How "If-Match" is different than "If-None-Match"? Should I support those 3 or just some of them? Any help welcome!