...
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 will not 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.
Info |
---|
NoteSwarm will return returns a 412 response if it cannot find the bucket or domain associated with a request. This can be distinguished from a cache response by the lack of the current ETag in the response headers and a response body that denotes that the bucket or domain cannot be located. |
...
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 only for exact equality.
In Swarm, ETag values are opaque, variable length, case-sensitive strings that must be 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 only 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. For example, you can use Use it in a READ request to prevent Swarm from returning "stale" bucket and domain data from the cache.
...
Swarm returns the ETag header for all POST, PUT, COPY, APPEND, GET, and HEAD operations. Swarm will use only uses "strong" ETags (as defined in RFC 7232 2.3) that can be compared only for exact (case-sensitive) equality.
...
The ETag of an immutable unnamed object never changes during the entire lifecycle of the object, whereas mutable named and unnamed object ETags change each time the object is mutated by a PUT.
Info |
---|
NoteYou cannot perform SCSP operations (Update, Delete, etc.) cannot be performed for an existing object using the ETag. |
...
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 will be are ignored.
Below are examples of If-Match request headers:
...
Swarm performs the requested method as if the If-Match header field did not exist if the entity tags match the primary UUID of the object returned in the response to a similar GET request (without the If-Match header) on that resource or if "*" is given. The If-Match header will be is ignored if the request results in anything other than a 2xx status without the If-Match header field.
Swarm will does not perform the requested method, and instead return a 412 Precondition Failed response with a current ETag header if none of the entity tags match. This behavior is most useful when the client wants to prevent an updating method (such as PUT) from modifying an aliased object that changed since the client last retrieved it.
Swarm will does not return a response status of 412 Precondition Failed unless it is consistent with all of the conditional header fields in the request if Swarm receives a conditional request that includes both a Last-Modified date (for example, in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags as cache validators (for example, in an If-Match header field).
...
A Swarm client or proxy can include this header with the PUT, COPY, APPEND, GET, and HEAD methods to make it conditional. This feature allows efficient cached information updates with a minimum amount of transaction overhead. The header value 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, anything after which will is be ignored.
Examples of If-None-Match request headers:
Code Block |
---|
If-None-Match: "508941dc9b52243f64d964b058354b76" If-None-Match: "508941dc9b52243f64d964b058354b76", "fe3233d3c6881d5e8b654117b829d26c" If-None-Match: W/"508941dc9b52243f64d964b058354b76" If-None-Match: */ |
Swarm will does not perform the requested method if the entity tags match the primary object UUID that is returned in the response to a similar GET request (without the If-None-Match header) on that object or if "*" is given and the object does exist. Swarm will respond responds with a 304 Not Modified response, including a current ETag header for the object if the request method was GET or HEAD. Swarm will respond responds with a response of 412 Precondition failed with the same current ETag as the GET or HEAD response for all other request methods. The object was modified if none of the previously recorded and supplied entity tags match. The requested method will proceed proceeds as if the If-None-Match header field did not exist.
Swarm will does not return a response status of 304 Not Modified or 412 Precondition failed unless it is consistent with all of the conditional header fields in the request if Swarm receives a conditional request that includes both a Last-Modified date (for example, in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags (for example, in an If-None-Match header field) as cache validators.
...
If the client has no entity tag for an object but has a Last-Modified date, it can use that date in an If-Range header. Swarm can distinguish between a valid HTTP-date and any form of entity-tag by looking for double quotes. The If-Range header should only be used together with a Range header, and will be is ignored if the request does not include a Range header.
If the entity tag given in the If-Range header matches the current primary object UUID or the HTTP-date given is not before the Last-Modified date of the object, Swarm will provide provides the specified sub-range of the object using a 206 Partial content response. If the entity tag does not match, Swarm will return returns the entire object using a 200 OK response.
...
Info |
---|
WarningAlthough Swarm supports this coherency method for compatibility reasons, it is not the preferred mechanism because of these issues and is not supported for rapid update use cases. ETag comparisons are recommended for cache coherency on objects that are rapidly updated. The value of each date header adheres to the Full Date Section 3.3.1 of the HTTP/1.1 specification and only dates in that format are recognized by Swarm on incoming requests. |
...
Swarm returns the Last-Modified header for all POST, PUT, COPY, APPEND, GET, and HEAD operations. For both ordinary objects and aliased objects, the value of the header will be is exactly the same as the Castor-System-Created header.
...
Info |
---|
Castor-System-Created deprecatedThe Castor-System-Created header is deprecated, replaced with the more standard Last-Modified header. For backward compatibility with previously stored data, Swarm will continue continues to generate both headers and behave as it does now if it encounters an object with a Castor-System-Created header, but without a Last-Modified header. If a stored object includes both headers, Swarm will use uses the value of the Last-Modified header. A future release will cease ceases generating the deprecated header for newly-stored content. |
...
Info |
---|
NoteIf-Modified-Since is for use with GET and HEAD requests only (not writes). If you specify specifying a date in the future, Swarm will ignore ignores it. |
If the requested object was not modified since the time specified in the If-Modified-Since header, an entity will is not be returned from the server. Instead, a 304 Not Modified response is returned without any message-body.
See Section 14.25 in the HTTP 1.1 specification for details.
Info |
---|
Best practiceIf you have storing frequently updated mutable objects that are frequently updated, use ETag comparisons, which offer cache coherency on objects that are rapidly updated objects. |
If-Unmodified-Since
A Swarm client or proxy can include this header with a GET, PUT, or DELETE method. All other methods ignore this header when present in the request. The If-Unmodified-Since request header field is used with a method to make it conditional.
If the requested object was not modified since the time specified in this field, Swarm performs the requested method as if the If-Unmodified-Since header were not present.
If the requested object was modified since the specified time, Swarm will does not perform the requested method, and instead, return a 412 Precondition failed.
If the specified date is invalid, the header is ignored.
...
Swarm returns an Expires header if it is persisted with your the content. Swarm does not generate an Expires header.
The Expires header field provides the final date and time when the response is considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with Swarm (or with an intermediate cache that has a fresh copy of the object). Since Swarm has no information about when an aliased object may be updated and little information about when an object may be deleted, Swarm does not generate an Expires header for any object. However, Expires will be are added to the list of persisted headers so that applications can supply a hint to caching proxies and clients as to when an object may become stale.