Quota and Size Properties for DAV Collections Network Resonance, Inc.2483 E. Bayshore RoadSuite 212Palo AltoCA94303US+1 415 812-7705briank@networkresonance.comOpen Source Applications Foundation543 Howard Street5th FloorSan FranciscoCA94105US+1 415 946-3040lisa@osafoundation.org
Applications
WWW Distributed Authoring and Versioning (webdav)quota WebDAV servers are frequently deployed with quota (size) limitations. This
document discusses the properties and minor behaviors needed for clients to
interoperate with quota (size) implementations on WebDAV repositories. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .
The definition of live property is provided in .
The definition of protected and computed properties is provided in
, Section 1.4.
WebDAV servers based on have been implemented and
deployed with quota restrictions on collections and users, so it makes sense to
standardize this functionality to improve user experience and client
interoperability.
The reasons why WebDAV servers frequently have quotas enforced are the same
reasons why any storage system comes with quotas. Sometimes the storage service charges according to quota Sometimes the storage service is provided free, but the storage service
provider has limited storage space (e.g.
university-provided student accounts) Even in cases where the storage can be upgraded, the storage managers
may choose to limit quota in order to encourage users to limit the files
they store on the system and to clean up obsolete files. (e.g. IT
departments within corporations) In order to work best with repositories that support quotas, client software
should be able to determine and display the DAV:quota-available-bytes
(defined below) on collections.
Further, client software should have some way of fairly reliably determining how
much storage space is already counted towards that quota. Support for the properties defined in this document
enhances the client experience, because the client has a chance of managing its files
to avoid
running out of allocated storage space. Clients may not be able to calculate the
value as accurately on their own, depending on how total space used is calculated by
the server. The approach to meeting the requirements and scenarios outlined above is to define
two live properties. This specification can be met on a server by implementing
both DAV:quota-available-bytes and DAV:quota-used-bytes on collections only. A <DAV:allprop> PROPFIND request SHOULD NOT return any of the properties
defined by this document.
However, these property names MUST be returned
in a <DAV:propname> request for a resource that supports the
properties, except in the case of infinite limits which are explained below. The DAV:quota-available-bytes and DAV:quota-used-bytes definitions below borrow heavily from the quota
definitions in the NFS specification.quota-available-bytesDAV:Indicates the maximum amount of additional storage
available to be allocated to a resource.<!ELEMENT quota-available-bytes (#PCDATA) > The DAV:quota-available-bytes property value is the value in octets representing the
amount of additional disk space beyond the current allocation that can be allocated
to this resource before further allocations will be refused. It is
understood that this space may be consumed by allocations to other resources. Support for this property is REQUIRED on collections, and OPTIONAL on other
resources. A server SHOULD implement this property for each resource that has the
DAV:quota-used-bytes property. Clients SHOULD expect that as the DAV:quota-available-bytes on a resource approaches
0, further allocations to that resource may be refused. A value of 0
indicates that users will probably not be able to perform operations that write
additional information (e.g. a PUT inside a collection), but may be able to replace
through overwrite an existing resource of equal size. Note that there may be a number of distinct but overlapping limits, which may even
include physical media limits. When reporting DAV:quota-available-bytes, the server is at
liberty to choose any of those limits but SHOULD do so in a repeatable way. The rule
may be configured per repository, or may be "choose the smallest number". If a resource has no quota enforced or unlimited storage ("infinite limits"), the
server MAY choose not to return this property (404 Not Found response in
Multi-Status), although this specification RECOMMENDS that servers return some
appropriate value (e.g. the amount of free disc space). A client cannot entirely
assume that there is no quota enforced on a resource that does not have this
property, but might as well act as if there is no quota. The value of this property is protected (see section 1.4.2 of
for the definition of protected properties). A 403 Forbidden response is RECOMMENDED for
attempts to write a protected property, and the server SHOULD include an
XML error body as defined by DeltaV with the
<DAV:cannot-modify-protected-property/> precondition tag.
quota-used-bytesDAV:Contains the amount of storage counted against the quota
on a resource.<!ELEMENT quota-used-bytes (#PCDATA) > The DAV:quota-used-bytes value is the value in octets representing the amount of
space used by this resource and possibly a number of other similar
resources, where the set of "similar" meets at least the criterion that allocating
space to any resource in the set will count against the DAV:quota-available-bytes.
It MUST include the total count including usage derived from sub-resources if
appropriate. It SHOULD include metadata storage size if metadata storage is counted
against the DAV:quota-available-bytes. Note that there may be a number of distinct but overlapping sets of
resources for which a DAV:quota-used-bytes is maintained (e.g. "all files with a given
owner", "all files with a given group owner", etc.). The server is at liberty to
choose any of those sets but SHOULD do so in a repeatable way. The rule may be
configured per repository. Support for this property is REQUIRED on collections, and OPTIONAL on other
resources. A server SHOULD implement this property for each resource that has the
DAV:quota-available-bytes property.
This value of this property is computed (see Section 1.4.3 of
for
the definition of computed property). A 403 Forbidden response is
RECOMMENDED for attempts to write a protected property, and the server
SHOULD include an XML error body as defined by DeltaV
with the
<DAV:cannot-modify-protected-property/> precondition tag.
WebDAV defines the status code 507 (Insufficient Storage).
This status code SHOULD be used when a client request (e.g. a PUT, PROPFIND, MKCOL,
MOVE or COPY) fails because it would exceed their quota or physical storage limits.
In order to
differentiate the response from other storage problems, the server SHOULD include an
XML error body as defined by DeltaV with the
appropriate precondition tag.
Preconditions:(DAV:quota-not-exceeded): the allocated quota MUST NOT be exceeded
by the request.
(DAV:sufficient-disk-space): there is sufficient physical space to
execute the request.
Implementation note: some client may be be able to take advantage of the different precondition codes when mapping to operating system status codes, such as E_NOSPC and E_DQUOT in NFS (see , Section 12).
Server implementations store and account for their data in many different ways. Some
of the challenges: Some server implementations find it prohibitive to count storage used for
metadata, others may choose to do so for better accounting. Older versions of resources may be stored as well. Variants of one resource may exist with different content lengths. Content may be dynamically generated. Resource bodies can be compressed. Some resources may be stored for "free", not counting against quota. Since server storage accounting can vary so much, clients should expect the
following: The size of a file on the client's file system, or in a PUT message, may not
correspond to the amount of storage required by the server to store the
resource. Thus, the client cannot predict with 100% accuracy whether a given
file will be allowed given the storage quota. Deleting or overwriting a resource may not free up the same amount of
storage as indicated by the DAV:getcontentlength property defined in for the resource. If deleting a resource does not free up
any space, the file may have been moved to a "trash" folder or "recycle
bin", or retained as in versioning systems ().
Since there are many factors that affect the storage used by a set of
resources, including automatic compression, the size of associated metadata,
and server-inserted content (such as that created by PHP code) in the
on-the-wire representation of resources, clients are advised to not depend
on the value of DAV:quota-used-bytes being the sum of the
DAV:getcontentlength properties for resources contained by a collection.
Additionally, because there may be a number of distinct but overlapping sets
of resources for which a DAV:quota-used-bytes is maintained
(),
there may be no correlation between the size of the resources in a
collection and DAV:quota-used-bytes. For example a server that implements
user-based quotas, DAV:quota-used-bytes usually will be the same for a
collection and it's members.
On some systems where quota is counted by collection and not by user, a
quota on a sub-collection may be larger than the quota on the parent
collection that contains it. For example, the quota on /~milele/ may be 100
MB, but the quota on /~milele/public/ may be unlimited. This allows the
space used by /~milele/public/ to be as large as the quota on /~milele/
allows (depending on the other contents of /~milele/) even if the quota on
/~milele/ is changed. Thus, even when the quota on a parent collection is
changed, it is not necessarily required to change the quota on every child
or descendant collection. A hacker may prefer to store files in collections with a large quota. This isn't
strictly a security concern because it doesn't make it any easier to store files. On
the other hand, the DAV:quota-used-bytes property may make it easier to detect
tampering or misuse. Quota is counted in Arabic numerals expressed in strings. There are no
internationalization considerations. There are no IANA considerations. Stefan Eissing, Geoff Clemm, Jim Luther, Julian Reschke, Jim Whitehead, among others, have
provided valuable comments on this document. Key words for use in RFCs to Indicate Requirement LevelsHarvard University Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)Rational SoftwareIBMIBMMicrosoftU.C. Santa CruzHTTP Extensions for Distributed Authoring -- WebDAVNetwork File System (NFS) version 4 Protocol