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

Jamie Lokier writes:

> A HTTP URL does not tell you the type of resource, only where to 
> find _a_ resource.

This misses an important point about http URIs and the HTTP protocol. 
Although the URL itself does not tell you the type of the resource, the 
response to an HTTP GET does indeed tell you the type of the entity body. 
So, you can access any such URI on the Web, and you'll either: (1) know 
how to interpret the response, I.e. because you recognize the Content-type 
and know how to process data of that type, or (2) will reliably discover 
that it's of a type you don't know how to process.  These characteristics 
are what make it possible for you to click on any link, and know that your 
browser won't misinterpret the results, even as new Content-types are 
deployed (well, let's not get into the sniffing discussion just now). It's 
also what allows search engine spiders to interpret the results returned 
from GETs on pretty much any http link.

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.

BTW: the above comment is not intended to express an opinion about the 
proposed ws/wss URI schemes; it's a reaction to Jamie's comment.  I do 
think it is an interesting question (I think I've raised it before), 
whether we expect search engines to come on ws/wss links, and if so, 
whether it's valuable for those search engines to be able to discover 
information about the resources identified by those links.

Noah

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

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Jamie Lokier <jamie@shareable.org>
Sent by: uri-request@w3.org
08/14/2009 05:37 PM
 
        To:     Kristof Zelechovski <giecrilj@stegny.2a.pl>
        cc:     "'David Booth'" <david@dbooth.org>, "'Ian Hickson'" 
<ian@hixie.ch>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: [hybi] [Uri-review] ws: and wss: schemes


Kristof Zelechovski wrote:
>  1.  Encouraging the user to enter a Web Sockets URL does not make sense 
if
> cross-domain connections are not allowed, which I hope will be the case 
(the
> draft specification [1] does not contain security considerations).

It was originally thought XHR (XmlHttpRequest) didn't need to be
cross-domain, but then people thought of lots of reasons why it's
useful and had to use hacks to workaround the limitation, so now
there's a draft standard to support cross-domain XHR - being careful
to address cross-domain security.

I suspect WebSockets could benefit from a look at the mechanisms used
by cross-domain XHR to check for permission to proceed.

>  2.  While we are at it, a Web Sockets connection is useless without 
knowing
> the protocol, and the protocol to be used is not contained within the 
URL.
> That means a ws URL is not self-contained and thus useless as a 
stand-alone
> locator.

The same is true of HTTP.

A HTTP URL does not tell you the type of resource, only where to find
_a_ resource.  For example there are places where a user can enter the
URL of a CalDAV calendar resource.  The CalDAV protocol is used (over
HTTP) to work with that resource, but the URL doesn't say what it is.

The only difference with WebSockets is that it (so far) seems to avoid
any descriptive metadata, which means there will still be applications
which ask for a WebSockets URL, but when the URL is for a different
protocol on top, it'll simply break with undefined behaviour instead
of a clean error message or fallback behaviour.

It doesn't matter if you think nobody should do that.  It will still
be done anyway - because it's so obviously useful.

-- Jamie

Received on Wednesday, 19 August 2009 16:22:12 UTC