Stale Cache in a Large System
Any client request can be directed to any node in the cluster because Swarm is a distributed system. Propagating actions takes time in a large distributed system. 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.
An INFO request after performing an UPDATE on a bucket's metadata may return the old metadata. The error stops after about twice the value of the cache.realmStaleTimeout configuration parameter. cache.realmStaleTimeout is set to 10 minutes by default. After about twice that time — 20 minutes — following the APPEND, the bucket is visible 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 deleting 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) are 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 may 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."