Caching metadata headers allows clients and caching proxies quickly determine if a resource was modified since the last time it was read. With alias objects, caching headers allow clients to verify the previous read is the current revision before writing an update to it. 

See SCSP Headers.

HTTP defines several header mechanisms for clients and caching proxies to quickly determine whether a resource was modified since the last time the data was read. In the Swarm context, caching headers make proxies more effective by extending the caching period to its maximum value, essentially telling the proxies that the resource does change for immutable objects.

To maintain compatibility with a wide variety of browsers and proxies, Swarm implements the caching mechanisms for both HTTP/1.0 and HTTP/1.1.

...

HTTP 1.1 Caching Headers

The newer HTTP/1.1 cache coherency mechanism does not use dates or timestamps and thus avoids the granularity and synchronization problems of the HTTP/1.0 headers. Instead, it uses entity tags (or ETags) that can be compared for exact equality.

In Swarm, ETag values are opaque, variable length, case-sensitive strings enclosed in quotes. Any characters preceding or following the quoted string are ignored. If the header value has no quoted string, the entire header is ignored. The value of each date header adheres to the Full Date specification(RFC 7232) , and dates in that format are recognized by Swarm on incoming requests.

...

Swarm also supports the Cache-Control: no-cache-context extension that instructs Swarm not to use cached contexts. (A context is a container; for example, the context of a named object is a bucket.) Cache-Control: no-cache-context can be used on any SCSP READ or WRITE request to instruct Swarm to ignore the content cache when looks up the bucket and domain for a named object. Use it in a READ request to prevent Swarm from returning "stale" bucket and domain data from the cache.

See Use the Content Cache in a Distributed System for See Application Best Practices for when Swarm may return "stale" data.

ETag

Swarm returns the ETag header for all POST, PUT, COPY, APPEND, GET, and HEAD operations. Swarm uses "strong" ETags (as defined in RFC 7232 2.3) that can be compared for exact (case-sensitive) equality.

...

The ETag of an immutable unnamed object does not change during the entire lifecycle of the object, whereas mutable named and unnamed object ETags change each time the object is mutated by a PUT.

...

If-Match

A Swarm client or proxy can include the If-Match header with the PUT, COPY, APPEND, GET, and HEAD methods. The value of the header is either a single quoted string (possibly with some ignored flags outside the quotation marks), a comma-separated list of quoted strings, or a single asterisk. Any additional strings are ignored.

...

In the first version of HTTP, the cache coherency mechanism used time stamps with one-second granularity to decide if a resource was modified and, therefore, required invalidating the cached copy. In addition to the course time granularity that can mask changes made in the same second (to aliased objects for example), this approach also requires the client and/or proxy clocks to be reasonably well synchronized with the server clocks.

...

• This is the original object time stamp for ordinary objects.

• This is the server time when the alias was last updated for aliased objects.

...

A Swarm client or proxy can include the If-Modified-Since header with a GET or HEAD method request. All other methods ignore the header when present in the request. The If-Modified-Since request header field is used with a GET to make it conditional.

...

An entity is not returned from the server if the requested object was not modified since the time specified in the If-Modified-Since header. Instead, an HTTP 304 Not Modified response is returned without any message-body.

See Section 14.25 in the HTTP 1.1 specification for details.

...