W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 2008

Re: Security considerations, was Re: Area Director feedback on draft-reschke-webdav-search-15 re supported query complexity

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 02 Jul 2008 21:24:16 +0200
Message-ID: <486BD5E0.5030008@gmx.de>
To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
CC: Jim Davis <jrd3@alum.mit.edu>, www-webdav-dasl@w3.org

Javier Godoy wrote:
> ...
>>    o  Query constraints on content (as with DAV:contains, defined in
>>       Section 5.16) for which the client does not have read access need
>>       to be evaluated as if a GET would return a 4xx status code.
> 
> And is the result of this evaluation FALSE? or is it UNKNOWN?
> I would expect the latter because expressions on properties evaluate as 
> UNKNOWN when the property is not defined, but Section 5.16 states that [[
>  The DAV:contains operator (...) evaluates to TRUE if the content of the 
> resource satisfies the search. Otherwise, it evaluates to FALSE.
> ]]

Would that be a problem?

I personally do not have a preference, and the DASL implementation I did 
a few years back did not support DAV:contains anyway.

> ...
>> I'm not too enthusiastic to add more RFC3744 related language; after 
>> all, some of the SEARCH implementations do not support RFC3744 anyway,
> 
> IMHO, if the DAV:supported-query-grammar-set property is REQUIRED when 
> both RFC 3744 and SEARCH are supported, then the interaction between 
> both extensions should have been regarded as important at some point in 
> the developement of DASL / SEARCH.

Honestly, I don't think so.

The text you're referring to was put in because the original feature 
discovery in DASL was broken (in that the DASL header uses URIs, while 
the request body uses expanded names), so this was put as an 
afterthought for "modern" servers.

>> so it seems to be a better approach to describe this in terms of 
>> whether the client is able to GET the content/PROPFIND a property 
>> (thus talk about status codes, not RFC3744 privileges).
> 
> I agree about not being too verbose about RFC 3744 details, but because 
> of a different reason: the *only* standard privilege (let alone the 
> DAV:acl property) from RFC 3744 that applies to SEARCH is DAV:read, 
> which affects both GET and PROPFIND. Generally, properties are 

Correct.

> controlled by DAV:read or by a non-standard privilege aggregated under 
> DAV:read. Therefore, the RFC 3744 language is not enough for defining 
> the behavior of the SEARCH method and GET/PROPFIND fits better.
> 
> Furthermore, SEARCH (at least, basicsearch) already defines it own 
> mechanism for advertising privileges in QSD responses. A property for 
> which the clien has no privileges is neither DAV:selectable, 
> DAV:searchable nor DAV:sortable... and that should be enough.

Which of course raises the question whether the result of QSD should 
reflect privileges; this may be very hard to implement.

> However, a brief statement about RFC 3744 in Section 7 should not harm 
> anyone (just a suggestion, it is up to you, +1 anyway)

Any proposals?

BR, Julian
Received on Wednesday, 2 July 2008 19:25:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:10 GMT