Using The Allow Metadata Header; Overview Of The Allow Header; Administrative Override - Dell DX6000 Application Manual

Chapter 17. Using the Allow Metadata Header
This chapter discusses the HTTP Allow entity header, which is used to specify which HTTP methods
can be executed for a given object.
For a list of all metadata headers supported by DX Storage, see

17.1. Overview of the Allow Header

The. GET and HEAD methods are always supported (regardless of the Allow header) so there is
no real use case for including an Allow header on a non-anchor object, although it is supported.
For anchor streams, however, the Allow header can meet several use cases. For example, for
users who only want an anchor stream to be mutable for a short time, the following header could be
included with a PUT request when the user is ready for the object to become immutable:
Allow: GET, HEAD
This removes PUT, COPY, and APPEND from the supported methods, effectively making the object
immutable.
When it is asked to perform some request on an anchor stream, the SCSP server will first examine
its metadata for the presence of an Allow header and, if found, it will return a 405 - Method not
allowed response for any method not found in the list. The error response will include the Allow
header stored with the anchor stream to provide guidance to the application about which methods
are allowed for this object. If no Allow header is stored with the anchor stream, the default is to allow
all methods except POST for anchor streams.
It is important to note that an anchor stream is dynamically deletable only 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.

17.2. Administrative Override

To prevent content from being stranded with no ability to delete or update it due to an overly
restrictive Allow header, DX Storage supports administrative override of the Allow header. The
primary use case for the override is to update the Allow header itself using a COPY request to
enable additional SCSP methods as needed.
To apply the administrative override, use the query argument ?admin[=yes|true] with the
request. 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 that DX Storage should evaluate the request for administrative
authorization. In addition to inclusion of the admin query argument, therefore, the user must be in
the CAStor administrator realm and the user must include their credentials with the request
in a standard HTTP Authorization header as defined by the HTTP/1.1 spec and the corollary
Authentication spec. The included Authorization header would look similar to the following:
Authorization: Digest username="JoAdmin", realm="Castor administrator",
uri="/bucketname/objectname", response="credentials_digest"
If the administrative request does not include an Authorization header with suitable administrative
credentials, DX Storage will respond to the request with 401 Unauthorized, which includes
Copyright © 2010 Caringo, Inc.
All rights reserved
the Content Metadata
64
appendix.
HTTP
Version 5.0
December 2010