The HTTP Allow entity-header is used to specify which HTTP methods can be executed for an unnamed object.

SeeSCSP HeadersSCSP Headers.

Allow for Alias Objects

The GET and HEAD methods are always supported (regardless of the Allow header), so there is no need to include an Allow header on an unnamed object. The Allow header can meet several use cases for alias objects. Use the following header with a PUT request when the user is ready for the object to become immutable if an alias object needs to be mutable for a short time:

This removes PUT, COPY, and APPEND from the supported methods, effectively making the object immutable.

The SCSP server first examines the metadata for the presence of an Allow header when asked to perform a request on an alias object. It returns a 405 - Method not allowed response for any method not found in the list if found. The error response includes the Allow header stored with the alias object to provide guidance to the application about which methods are allowed for this object. The default result is to allow all methods except POST for alias objects if no Allow header is stored with the alias object.

An alias object is dynamically deletable if the DELETE is included in the Allow header and its current lifepoint allows deletes (deletable=yes). The Allow header has no effect on automatic deletes specified in lifepoint headers, which cause an object to be deleted at a certain point in time. Such lifepoint deletes do not require executing a DELETE method, and therefore do not contradict any Allow header that may not include support for deletes.

Administrative Override

To prevent content from being stranded with no ability to delete or update it due to an overly restrictive Allow header, Swarm supports administrative override of the Allow header.

Use the query argument admin[=yes|true] with the request to apply the administrative override. admin with no optional argument defaults to true. Any value other than yes or true is interpreted as false and the administrative override request is ignored.

The admin query argument indicates Swarm should evaluate the request for administrative authorization. The user must be in the CAStor administrator user list and include credentials with the request in a standard HTTP Authorization header in addition to including the admin query argument, as defined by the HTTP/1.1 spec and the corollary HTTP Authentication specification.

Example of an Authorization header:

• Bad Credentials: If the administrative request does not include an Authorization header with suitable administrative credentials, Swarm responds to the request with 401 Unauthorized, which includes a WWW-Authenticate challenge containing the administrative domain named Castor administrator and other required items.

• Good Credentials: If the request includes both the query argument and authorized administrator credentials, it proceeds and the Allow header is ignored.

Administrative overrides cannot be used for unsupported methods for an object. Update methods like PUT, COPY, or APPEND to immutable objects. Consider writing the object as an alias object with an Allow header not including the update methods if immutability may need to be overridden in the future: This prevents normal users from modifying the object but allows the administrator to update it using an authorized administrative request, if needed.

All administrative requests are logged along with the user name of the requester for audit purposes.

Evaluating Success

Swarm examines the following to determine whether a particular SCSP method succeeds:

1. The admin query argument bypasses other authorization methods.

2. The methods allowed by the Allow header.