Subject: HTTP URI scheme

From: Jay Daley <[email-masked]>
Date: Thu, 11 Jan 2007 22:13:14 +0000

Hi

Can anyone point me to an explanation as to why  WebDAV uses http:// as 
the URI scheme instead of something WebDAV specific that would signal when 
a URI is WebDAV compliant?  I've had a go at searching the lists but can't 
find not the reasoning behind it.

thanks in advance

Jay Daley
Nominet UK

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Jan 2007 10:12:34 +0100

> find not the reasoning behind it.

Well, a WebDAV resource *is* an HTTP resource. Why would you create a 
new URI scheme? Would you also create new URI schemes for WebDAV ACL, 
WebDAV DeltaV and so on...? (*)

The capabilities of an HTTP resource can be discovered reliably at 
runtime, either by just trying (and let the server fail), or by using 
the OPTIONS method.

Best regards, Julian

(*) Yes, Apple did something similar with iTunes and iCal, but I think 
there's wide agreement that was a mistake.

---

From: Werner Donné <[email-masked]>
Date: Fri, 12 Jan 2007 10:34:51 +0100

Hi,

Implementing an efficient client is a challenge if you have to
discover the capabilities at run-time. Either you end up with
a lot of OPTIONS method calls or a lot of state to avoid them.
Another alternative is recovery code for failures all over the
place, because you can't just fail without telling the user
in a proper way what the problem is, which depends on the
scenario he is in. "Not implemented" is not good enough when
it is about something deep inside some logic that the user has
triggered, because he will not be able to related it to what
he did.

Why exactly what Apple did was a mistake?

Regards,

Werner.

Julian Reschke wrote:
> 
> Jay Daley schrieb:
>> Hi
>>
>> Can anyone point me to an explanation as to why  WebDAV uses http:// 
>> as the URI scheme instead of something WebDAV specific that would 
>> signal when a URI is WebDAV compliant?  I've had a go at searching the 
>> lists but can't find not the reasoning behind it.
>>
>> thanks in advance
> 

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Jan 2007 10:46:06 +0100

> discover the capabilities at run-time. Either you end up with

Where exactly would a "webdav" scheme help here? Can you give a 
definition what information it would provide? Would I be allowed to use 
it for resources that just support PROPFIND, for instance?

-> Granularity problem, for once.

> scenario he is in. "Not implemented" is not good enough when

That's why the newer WebDAV specs provide DAV:error. And again, how 
would a different URI scheme help here?

> Why exactly what Apple did was a mistake?

For once, because they forced new identifiers on the web, without taking 
care of specifying what they mean (or did I miss a scheme registration?).

As far as I can tell, the only way they differ from HTTP URLs is that 
Apple's software uses them to invoke a different user agent. You don't 
need an URI scheme for that, a MIME type works just fine (see, for 
instance, <http://greenbytes.de/tech/webdav/rfc4709.html#rfc.section.A.2>).

Best regards, Julian

---

From: Werner Donné <[email-masked]>
Date: Fri, 12 Jan 2007 11:26:43 +0100

> it for resources that just support PROPFIND, for instance?

No, of course not. The scheme tells you you can rely on all the
mandatory features of the WebDAV protocol, which allows you to
switch to another protocol handler without the extra round-trip
to find that out.

A failure in that case can be considered as a low-level system failure,
which is in general handled with much simpler logic than what you
need if you have to be very lenient in the middle of application
logic. The former is an exception and can be dealth with as such.

> would a different URI scheme help here?

The DAV:error just gives you a report about the point of failure.
It is not necessarily the case that the action of the user is
directly related to that point. He could have launched a procedure
which comprise much more than what you would typically expect
behind a link in a browser.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Jan 2007 12:08:15 +0100

Werner Donné schrieb:
>> definition what information it would provide? Would I be allowed to 
>> use it for resources that just support PROPFIND, for instance?
> 

A server that does only support PROPFIND and fails all other WebDAV 
requests with not authorized could be compliant (it may support those 
methods at a different point of time, or for different users).

Furthermore: DAV level 1 or 2?

I think the important point is that having different protocol handlers 
may be the wrong way to approach that problem.

> ..

> behind a link in a browser.

Again: how would a different URI scheme help here? Concrete example, please?

 > ...

Best regards, Julian

---

From: Jay Daley <[email-masked]>
Date: Wed, 17 Jan 2007 11:44:11 +0000

> may be the wrong way to approach that problem.

Here are some concrete examples of why having a separate protocol handler 
would help:

1.  Suppose a new browser comes out that is super-fast and I decide to use 
it as my standard browser and so my OS is set to use this as the default 
browser.  However this browser does not support WebDAV.

I then receive an email with a link to a collection on a WebDAV enabled 
server, that has the form http://....  So I click on the link and my 
browser does what it can but that is no use to me since I need the WebDAV 
compliance.

I then have to cut and paste the URL into a WebDAV compliant application 
and access it that way.

The alternative is that the link arrives in the form webdav://.... So my 
OS now has two defaults set up, one for the default browser and one for 
the default WebDAV application.  I have only changed the former when I 
installed my new browser so clicking on the link still invokes my WebDAV 
application and it all works.

2.  Suppose I am a fairly technical IT person, who has never heard of 
WebDAV.  I receive an email with a link to a WebDAV compliant resource 
that is of the form http://....  Well I am none the wiser.  I don't know 
this is a WebDAV server, I don't know that I could do so much more than 
just retrieve the document.  In fact if I receive a "Forbidden to access" 
error then I might believe the whole thing is broken.

However, suppose I receive an email with a link of the form webdav://.... 
Well I realise I don't know what this is so I go and learn about it.  I 
download a WebDAV compliant app, or I discover that some of my apps are 
already WebDAV compliant.  I even start to think about how I might use 
WebDAV inside my company. 

The insistence on the http:// scheme means that WebDAV is *invisible*. 
After a decade it is probably less well know than something like ENUM.  I 
would suggest that the use of the http:// scheme is one of the biggest 
factors in contributing to this invisibility.

Jay Daley
Nominet UK

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jan 2007 13:20:30 +0100

> browser.  However this browser does not support WebDAV.

So, do you actually have a browser that "supports" WebDAV? Otherwise 
that concern seems to be really irrelevant.

> browser does what it can but that is no use to me since I need the WebDAV 

The only platform-agnostic way to cause a specific WebDAV compatible 
client to be launched is described in RFC4709, and was written so it can 
be implemented in any user agent that allows to invoke applications 
based on MIME types. As far as I can tell, all common browsers allow 
that (normally relying on the underlying operating system's support for 
that).

> application and it all works.

That's one alternative. RFC4709 describes another one which doesn't 
require an additional protocol.

> error then I might believe the whole thing is broken.

Why would you receive a "forbidden to access" error?

> factors in contributing to this invisibility.

That sort-of implies that "visibility" is an advantage. I don't agree 
here. I prefer seamless integration with the classic Web.

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 17 Jan 2007 16:30:53 -0800

Not entirely true.  The one drawback is that you have to launch  
*some* agent before you can find out which agent should be handling  
the URI.  Plus, it's possible that said agent wants the full response,  
not just the body.  So you end up with:

   - User clicks http://phobos.apple.com/...
   - Safari launches
   - Safari opens the URL
   - Safari realizes this URL is meant for iTunes
   - iTunes launches
   - iTunes opens the URL

   The Safari steps (particularly expensive if it wasn't already  
running) are all avoided with the itms:// scheme hack.  Which isn't to  
say it's not the wrong way to do it, but it certainly isn't "just as  
good" to rely on the MIME type.

	-wsv

On Jan 12, 2007, at 1:46 AM, Julian Reschke wrote:

> As far as I can tell, the only way they differ from HTTP URLs is  
> that Apple's software uses them to invoke a different user agent.  
> You don't need an URI scheme for that, a MIME type works just fine  
> (see, for instance, <http://greenbytes.de/tech/webdav/rfc4709.html#rfc.section.A.2 
> >).