W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2006

BugZilla issue 213: PROPFIND consistencies

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 26 Apr 2006 18:54:27 +0200
Message-ID: <444FA5C3.1070109@gmx.de>
To: w3c-dist-auth@w3.org

Hi,

the proposed patches below fixes several problems with PROPFIND, some of 
which were recorded in BugZilla issue 213 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=213>):


Section 9.1., para. 2:
OLD:

    A client MUST submit a Depth header with a value of "0", "1", or
    "infinity" with a PROPFIND request.  Servers MUST support "0" and "1"
    depth requests on WebDAV-compliant resources and SHOULD support
    "infinity" requests.  In practice, support for depth infinity
    requests MAY be disabled, due to the performance and security
    concerns associated with this behavior.  Since clients weren't
    required to include the Depth header in [RFC2518], servers SHOULD
    treat such a request as if a "Depth: infinity" header was included.

NEW:

    A client may submit a Depth header with a value of "0", "1", or
    "infinity" with a PROPFIND request.  Servers MUST support "0" and "1"
    depth requests on WebDAV-compliant resources and SHOULD support
    "infinity" requests.  In practice, support for depth infinity
    requests MAY be disabled, due to the performance and security
    concerns associated with this behavior.  By default, the PROPFIND
    method without a Depth header MUST act as if a "Depth: infinity"
    header was included.

Discussion: requiring clients to send the Depth header (MUST), but also 
requiring servers to handle missing headers (SHOULD) does not make 
sense. If servers can not rely on the presence of the request header for 
backwards compatibility anyway, introducing a MUST level requirement to 
send just doesn't make any sense.

Proposal to revert to original language (note that otherwise this Change 
would need to be added to the Changes section).


Section 9.1., para. 4:
OLD:

     o  Request particular property values, by naming the properties
        desired within the 'prop' element (the ordering of properties in
        here MAY be ignored by server),

NEW:

     o  Request particular property values, by naming the properties
        desired within the 'prop' element,

Nothing in the spec indicates that ordering is relevant here, so 
mentioning it here IMHO is confusing.



Section 9.1., para. 10:
OLD:

    If there is an error retrieving a property then a proper error result
    MUST be included in the response.  A request to retrieve the value of
    a property which does not exist is an error and MUST be noted, if the
    response uses a 'multistatus' XML element, with a 'response' XML
    element which contains a 404 (Not Found) status value.

NEW:

    If there is an error retrieving a property then a proper error result
    MUST be included in the response.  A request to retrieve the value of
    a property which does not exist is an error and MUST be noted, with a
    'response' XML element which contains a 404 (Not Found) status value.

I think this is confusing, because it's always a Multistatus, right?


Section 9.1.1., para. 2:
OLD:

    403 Forbidden - A server MAY reject PROPFIND requests on collections
    with depth header of "Infinity", in which case it SHOULD use this
    error with the precondition code 'propfind-finite-depth' inside the
    error body.

NEW:

    403 Forbidden - A server MAY reject PROPFIND requests with depth
    header of "Infinity", in which case it SHOULD use this error with the
    precondition code 'propfind-finite-depth' inside the error body.

s/on collections//. The request may be rejected on any type of resource.


Section 9.1.2., para. 2:
OLD:

       200 OK - A property exists and/or its value is successfully
       returned.

       401 Unauthorized - The property cannot be viewed without
       appropriate authorization.

       403 Forbidden - The property cannot be viewed regardless of
       authentication.

       404 Not Found - The property does not exist.

NEW:

    200 OK - A property exists and/or its value is successfully returned.

    401 Unauthorized - The property cannot be viewed without appropriate
    authorization.

    403 Forbidden - The property cannot be viewed regardless of
    authentication.

    404 Not Found - The property does not exist.

(Indentation inconsistent with other sections)


Section 16., para. 31:
OLD:

    Purpose:  (precondition) -- This server does not allow infinite-depth
       PROPFIND requests on collections.

NEW:

    Purpose:  (precondition) -- This server does not allow infinite-depth
       PROPFIND requests.


Again, strike "on collections".



Best regards, Julian
Received on Wednesday, 26 April 2006 17:03:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:14 GMT