Stale Cache in a Large System
Because Swarm is a distributed system, any given client request can be directed to any node in the cluster. In a large distributed system, propagating actions takes time. Certain types of transient errors can result after executing an SCSP "change" method, such as COPY, APPEND, UPDATE, and DELETE. (This also applies to WRITE, which is not considered a change method.)
For example, after you UPDATE a bucket's metadata, an INFO request for that bucket might return the old metadata. The error stops after about twice the value of the cache.realmStaleTimeout configuration parameter. (By default, cache.realmStaleTimeout is set to 10 minutes. After about twice that time — 20 minutes — following the APPEND, the bucket is "seen" by all nodes in the cluster.)
Tasks that include these transient errors include:
Using SCSP UPDATE to replace a bucket's metadata.
Deleting a bucket and creating a new bucket with the same name.
Using SCSP COPY to add custom metadata to a bucket or domain.
After about twice the value of the cache.realmStaleTimeout configuration parameter occurs, the same task should succeed.
Important
These examples apply to buckets and domains and not to named and unnamed objects. Before you delete a bucket, delete or move the objects it contains.
Workarounds for Redirect Issues
Some HTTP client libraries and frameworks do not handle redirects correctly for WRITE requests, at least not by default. Older versions of the HTTP protocol (namely HTTP 1.0) were lax in the specification of exactly what the client must do when it receives a 301 or a 307 response code. Because of this, older clients, including many web browsers, developed separate own conventions. While some of these conventions might be useful, they are in direct violation of the HTTP/1.1 specification and therefore incompatible with Swarm.
Both the Microsoft .NET framework and the libCURL framework (and probably others) are known to process a redirect from a POST request by changing the POST to a GET and then sending the new request to the redirect server. Workarounds exist in the impacted frameworks because the behavior is known to be in violation of the specification.
According to RFC 2616: "When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP 1.0 user agents will erroneously change it into a GET request."