Subject: Format of DAV:get* properties

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 12:18:15 +0100

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 25 Nov 2003 09:41:05 -0800

This hasn't been a problem in the WFS implementation.  The unusual
formatting is rare, and so users can generally search on "contains 
'text/plain'" and get all the results they need.  Sometimes it's 
not worth dealing with edge cases in a spec, beyond noting that 
they exist and noting that servers can easily normalize the value
to reduce the existence of edge cases.

However, I'm not sure how much of an edge case it is.  If it's been
a problem in practice, the 'media-type-match' syntax seems to be an
elegant and effective way to deal with it.

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Tuesday, November 25, 2003 3:18 AM
> To: [email-masked]'; [email-masked]
> Subject: Format of DAV:get* properties
> 
> 
> 
> Hi,
>