Subject: Recognizing a WebDAV enabled client

From: Michael Wechner <[email-masked]>
Date: Fri, 30 Jun 2006 09:37:21 +0200

Hi

It's not clear to me how a server can recognize a WebDAV enabled client 
from a GET request and
also how the client can communicate the version of WebDAV which the 
client has implemented.

I have seen in the spec that one can set  the HTTP header parameter DAV: 
1,.... but it seems to
be that nobody is really doing this, but rather people are using 
reserved ports or URI prefixes as workarounds for
WebDAV GET requests, but which seems to me leads to a lot of code 
duplication and other issues
(for instance having to open a specific port within a firewall, etc.).

Any pointer re this problem is very much appreciated.

Thanks

Michi

-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
[email-masked]                        [email-masked]
+41 44 272 91 61

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jun 2006 09:50:04 +0200

> It's not clear to me how a server can recognize a WebDAV enabled client 

It can't.

> also how the client can communicate the version of WebDAV which the 

Same.

Why would the server care?

> I have seen in the spec that one can set  the HTTP header parameter DAV: 

No, (in RFC2518) that's a response header. RFC2518bis allows extensions 
to use this as a request header, but so far BIND is the only one using it.

> Any pointer re this problem is very much appreciated.

I guess you'll need to explain first what the problem is.

The answer to GET should never depend on whether the client knows about 
WebDAV or not.

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 30 Jun 2006 09:59:10 +0200

Hi,

On Jun 30, 2006, at 9:50 AM, Julian Reschke wrote:

> Michael Wechner schrieb:
>> Hi
>> It's not clear to me how a server can recognize a WebDAV enabled  
>> client from a GET request and
>
> It can't.

I will run into the same question in the near future, so let me get  
this right:

I have implemented an HTTP resource for something collection-like and  
like to serve that up as HTML lists or WebDAV collections depending  
on the client capabilities. Are you saying I cannot detect if I am  
talking to a client that can handles WebDAV collections or not?  
That's seems silly.

Jan

---

From: Michael Wechner <[email-masked]>
Date: Fri, 30 Jun 2006 10:09:15 +0200

> Why would the server care?
 
because the server might be able to handle different versions of WebDAV. 
I think this makes sense
for backward and forward compatibility reasons.

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.
>
>> I have seen in the spec that one can set  the HTTP header parameter 
>> DAV: 1,.... but it seems to
>
> No, (in RFC2518) that's a response header. RFC2518bis allows 
> extensions to use this as a request header, but so far BIND is the 
> only one using it.

ok
> I guess you'll need to explain first what the problem is.

please see above or let me know if I shall provide other examples why I 
think it would be good
to be able to differentiate between a WebDAV client and whatever.

All the best

Michi

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jun 2006 10:09:27 +0200

Jan Algermissen schrieb:
> I will run into the same question in the near future, so let me get this 
> right:
> 
> like to serve that up as HTML lists or WebDAV collections depending on 
> the client capabilities. Are you saying I cannot detect if I am talking 
> to a client that can handles WebDAV collections or not? That's seems silly.

If a client does a GET on that URL, return HTML. If a client does a 
PROPFIND on that URL, return a XML multistatus response body.

What am I missing?

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 30 Jun 2006 10:17:40 +0200

On Jun 30, 2006, at 10:09 AM, Julian Reschke wrote:

>> I will run into the same question in the near future, so let me  
>> get this right:
>> I have implemented an HTTP resource for something collection-like  
>> and like to serve that up as HTML lists or WebDAV collections  
>> depending on the client capabilities. Are you saying I cannot  
>> detect if I am talking to a client that can handles WebDAV  
>> collections or not? That's seems silly.
>

Ah, ok (have not really used WebDAV, so this is not in my bones).

> What am I missing?

Nothing, thanks.

Jan

---

From: Michael Wechner <[email-masked]>
Date: Fri, 30 Jun 2006 10:20:37 +0200

> PROPFIND on that URL, return a XML multistatus response body.

this might working for collections, because PROPFIND exists ;-) and 
hence allows differentiation
> What am I missing?

as I described I think there are good reaons that also a GET request 
needs differentiation, but also more generally being
able to recognize the version.

Thanks

Michi

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jun 2006 10:30:26 +0200

> for backward and forward compatibility reasons.

Well, so far there are no different versions, so the server doesn't need 
to know.

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

> the server might respond with an ODT file.

Well, that's what the HTTP "Accept" request header is for.

 > ...

Best regards, Julian

---

From: Manfred Baedke <[email-masked]>
Date: Fri, 30 Jun 2006 11:32:57 +0200

Hi Michael,

> Also the server might want to deliver a different response, e.g. if 
> the GET request is being issued from a regular Web-Browser,

What about the Accept header?

> because the server might be able to handle different versions of 
> WebDAV. I think this makes sense

Are there any specific incompatibility issues you are aware of ?

Regards,
Manfred

---

From: Michael Wechner <[email-masked]>
Date: Fri, 30 Jun 2006 15:55:22 +0200

Julian Reschke wrote:
> Well, so far there are no different versions, so the server doesn't 
> need to know.

but I guess there will be someday ;-)
> <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?
> 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).

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.

All the best

Michi

---

From: Michael Wechner <[email-masked]>
Date: Fri, 30 Jun 2006 15:58:35 +0200

> What about the Accept header?

makes sense, whereas I need to check what OpenOffice for instance is 
actually sending, but see my other usecase re
custom authentication.
> Are there any specific incompatibility issues you are aware of ?
no, but I could imagine there will be if there will be more than one 
version of WebDAV and so I think it should
me mandatory for clients to send the DAV header.

Cheers

Michi

---

From: Joe Feise <[email-masked]>
Date: Fri, 30 Jun 2006 07:30:04 -0700

> WebDAV far enough how something like this could be handled by the WebDAV 

Authentication is independent of the response body.
It is all done in the HTTP headers.
Nothing prevents a client to send an Authorization header without receiving a
401 response beforehand (RFC 2616, section 14.8.)
And servers are free to send multiple WWW-Authenticate headers, for each one of
the authentication schemes they support (for example, IIS can indicate support
for the custom NTLM authentication.)
So, I still fail to see what the problem is.

-Joe