Re: [hybi] [Uri-review] ws: and wss: schemes

[John Kemp <[e-mail]>]

Jamie Lokier wrote:
> [e-mail] wrote:
>> Jamie Lokier writes:

...

>  Given a URI, you
> cannot tell from Content-Type whether that URI supports WebDAV,

However, the WebDAV specification does specifically offer some level of 
compatibility with existing non-WebDAV-aware clients - 
http://tools.ietf.org/html/rfc4918#appendix-B

Without a WebDAV-aware client, I can still perform some non-WebDAV HTTP 
requests.

With a WebDAV-aware client, I can perform WebDAV HTTP requests which the 
server may or may not support, but the server can tell me, according to 
HTTP specification that a "method is not supported".

> and
> you cannot tell whether that URI accepts POSTs to submit new blog
> entries - just to pick two widely used examples.

A client able to submit a POST can try, but might fail.

> 
> That requires another level of descriptive metadata, which
> Content-Type does not provide and is not always available in any other
> form.  But, just like people can enter a "blog posting" URI into their
> mobile phone, there will be reasons why people enter WebSockets URIs
> into applications, with no way for the application to verify the
> protocol except by trying it.

The question is perhaps really about whether you want to provide _some_ 
compatibility with existing non-websock-aware clients.

> 
>> So, this is a desirable characteristic for Web resources, and it's
>> one of the things that HTTP gives you.  Indeed, the whole Web is
>> designed so that you can start with RFC 3986, the specification for
>> URIs, and using the references to which it (recursively) delegates,
>> discover how to correctly interact with and interpret responses from
>> any resource on the Web.  Under the auspices of the W3C TAG, I
>> prepared a "finding" [1] that goes into more detail on these issues
>> and their implications.
> 
> In other words, I disagree with the above.  You can't find which
> particular protocols are overlaid on top of HTTP at every findable URI
> by the existing mechanisms, and it's unlikely that will ever be
> possible.

It is possible for those designing Web protocols to consider 
compatibility with existing Web client software, and to provide ways of 
allowing new and existing clients to determine the capabilities of 
HTTP-identified resources. The TAG finding that Noah mentions describes 
ways in which (some) others have allowed for clients to "follow their 
noses" and discover how to operate with servers regarding particular 
resources. There are other ways to do it, but the point is that it 
depends on protocol designers making the decision to offer such 
facilities. Using HTTP URIs to identify resources is a good way to begin 
that process.

Regards,

- johnk

[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html