HTTP If-None-Match vs. If-Match

Question

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!

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 )

Comments

[AlexV]

Is there situation where If-Match, If-Unmodified-Since or If-Range can trigger a HTTP 304 "Not Modified" answer?

[St.Woland]

No, it's only allowed for If-None-Match and If-Modified-Since. en.wikipedia.org/wiki/List_of_HTTP_headers

[Vicary]

Isn't that If-Match: * conflicts with 404?

[Vicary]

Answering my own question, If-Match has a condition that make itself the last resolve chain, therefore 404 normally takes precedence.