Re: Recognizing a WebDAV enabled client

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.

>> 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>).

>>> 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.

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.

> 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.

Best regards, Julian

Received on Saturday, 1 July 2006 07:48:43 UTC