Search Results
  1. HTTP (Hypertext Transfer Protocol)
  1. HTTP Headers
  1. If-None-Match
    1. Writing requests (clients)
      1. Freshining a cache
      2. Creating a new resource
    2. Reading requests (caches)
    3. Reading requests (origins)
    4. Overview table
    5. Syntax
      1. Examples
    6. History

If-None-Match

The "If-None-Match" header makes the request conditional on the target resource (on the cache or origin) having changed from the specified ETag. ETags are compared using the weak validation function (i.e. the weak flag is ignored when comparing ETags). This form is typically used when freshining a cache. If the request fails (i.e. the resource is unchanged), the server will respond with 304 (Not Modified); otherwise, the request will proceed. The equivelant header for Last-Modified is If-Modified-Since.

The Last-Modified equivelant is If-Modified-Since.

If the value is *, then the request becomes conditional on the resource not existing. This form is typically used when creating resources, so that an existing resource is not overwritten. If the request fails, the server will respond with 412 (Precondition Failed); otherwise, the request will proceed.

Writing requests (clients)

Freshining a cache

Use If-None-Match in requests for resources that are already cached by the client, see HTTP Caching for details.

Creating a new resource

Clients should use If-None-Match: * when creating a resource that is not expected to exist (with e.g. PUT or PATCH).

Reading requests (caches)

Caches may test conditional headers and respond to directly to requests without contacting the inbound server. See "Handling a Received Validation Request" in RFC7234 for instructions on how caches handle conditional headers.

Reading requests (origins)

Conditional requests should be tested after the resource has been looked up, a representation has been selected, and authorization to access the resource has been verified. See the ETag header for guidence on how to compute the ETag, for performance, it should not need to involve generating the entire resource.

Servers that wish to prevent lost updates may require that unsafe requests be accompanied by a conditional header, see 428 Precondition Required.

If the value is * and the resource exists, return 304 (Not Modified) (safe methods) or 412 (Precondition Failed) (unsafe methods).

If the value is the ETag form, use the strong comparison function to compare each ETag to the resource's current ETag. If none of the comparisons match, return 304 (Not Modified) (safe methods) or 412 (Precondition Failed) (unsafe methods).

Overview table

Name
If-None-Match
Description
Makes request conditional on target resource having been changed.
Direction
Request
Specification
RFC 9110: HTTP Semantics §13.1.2. If-None-Match

Syntax

If-None-Match = "*" / 1#entity-tag

Examples

If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

History

  1. 1999-06: RFC 2616 §14.26. If-None-Match
  2. 2014-06: RFC 7232 §3.2. If-None-Match
  3. 2022-06: RFC 9110 §13.1.2. If-None-Match