Re: Recognizing a WebDAV enabled client

Julian Reschke wrote:
> Michael Wechner schrieb:
>>> Well, so far there are no different versions, so the server doesn't 
>>> need to know.
>>
>> but I guess there will be someday ;-)
>
> I think that if this happens the working group made a grave mistake.

grave mistakes can happen all the time, so I think one should be 
prepared from the very beginning

(thinking about the Titanic or Goedel's incompleteness theorem, whereas 
I don't think Goedel's theorem is wrong, but
it rather shows nicely that unexpectable stuff can happen ... ;-)
>
>>> If a spec revision or an extension should introduce a change where 
>>> the server does need to know, the client *then* can send the DAV 
>>> request header, as defined in 
>>> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-15.html#dav-header>. 
>>>
>>
>> ok. Do you know by any chance why BIND in particular is using this 
>> header?
>
> Sure. It's needed to that a client can communicate to the server that 
> it knows about the status code 208, which a server may use to collapse 
> repeating information in a PROPFIND response (see 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-14.html#rfc.section.7.1>). 
>

thanks for the explanation
>
>>>> Also the server might want to deliver a different response, e.g. if 
>>>> the GET request is being issued from a regular Web-Browser,
>>>> then the server might respond with a common (X)HTML, but if the GET 
>>>> request is being issued from Cadaver or OpenOffice then
>>>> the server might respond with an ODT file.
>>>
>>> Well, that's what the HTTP "Accept" request header is for.
>>
>> right, this might makes sense for formats. But I would argue with 
>> another usecase, namely Custom Authentication
>> instead of HTTP authentication (BASIC or DIGEST).
>
> "Custom" authentication basically is authentication that bypasses 
> RFC2617. I know it's common, but it's not covered by IETF specs right 
> now. I agree that this is a problem that needs to be worked on, but I 
> fail to see how this is a WebDAV problem.

agreed, but are you aware of anyone trying to solve the problem of 
"custom" authentication?
>
> In particular, for WebDAV it's quite simple: the server should always 
> do RFC2617-based authentication if the request method is OPTIONS or 
> PROPFIND.
>
> Things get harder with non-browser based protocols such as AtomPut 
> that do *not* use specific verbs.

well, I am coming from a similar background ;-)
>
>> Let's assume a resource is protected and a server would like to offer 
>> custom authentication, e.g. it would send
>> a HTML to a regular browser and some WebDAV specific XML to a WebDAV 
>> enabled client, whereas I haven't digged into
>> WebDAV far enough how something like this could be handled by the 
>> WebDAV spec.
>
> The WebDAV spec doesn't care, and doesn't need to.

thanks for clarifying

All the best

Michi
>
> Best regards, Julian
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org
+41 44 272 91 61

Received on Monday, 3 July 2006 14:21:34 UTC