Re: BugZilla issue 213: PROPFIND consistencies

+1

Julian Reschke wrote:
> 
> 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 Thursday, 4 May 2006 22:22:37 UTC