Format of DAV:get* properties

Hi,

I was just trying to come up with a DAV:basicsearch query that would 
match on the DAV:getcontenttype property (instead of making assumptions 
about file names).

However, a combination of

- complex media type syntax 
(<http://greenbytes.de/tech/webdav/rfc2616.html#media.types>),
- HTTP white space handling in headers and
- deficiencies in the DAV:like operator

makes this *really* hard. To illustrate the problem, all of the 
following are legal values for the HTTP content-type header for a 
"text/plain" resource:

1) "text/plain"

2) "text/plain; charset=UTF-8"

3) "text/plain ; charset=UTF-8"

4) "text/plain;\tcharset=UTF-8"

5) "text/plain\r\n\t;charset=UTF8"

(where \r, \n and \t are CR, LF and HT).

If we add linear white space at the start of the attribute value, things 
get even more complicated.

One way to approach this issue is to find out whether existing DAV 
servers indeed use all these variants, or whether in practice only 
single SPs appear as whitespace (which would make sense in 
DAV:getcontenttype). In that case, we'd only need to consider variants 
1...3.

Alternatively, the SEARCH spec could state that matching on DAV:get* 
headers occurs after whitespace normalization.

In both cases, a match for "text/plain" could be expressed as:

(DAV:getcontenttype LIKE "text/plain") OR (DAV:getcontenttype LIKE 
"text/plain %") OR (DAV:getcontenttype LIKE "text/plain;%")

This is still ugly, but if we add that as example to the spec, servers 
may be able to optimize this case internally.

An alternative would be to add a specific operator that specializes on 
matching media types minus parameters, such as

<media-type-match>
   <type>text</text>
   <subtype>plain<</subtype>
</media-type-match>

where both child elements would be optional and probably use LIKE syntax 
(in caseless mode).

Feedback appreciated,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 25 November 2003 06:18:18 UTC