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

[Jamie Lokier <[e-mail]>]

[e-mail] wrote:
> 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.

Firstly, I agree with the usefulness of Content-Type, which is why I
think it would be helpful if the WebSockets protocol defined something
equivalent, even just a single string to identify the protocol at the
start.

Secondly, this thread has talked about protocols on top of protocols
(because every WebSockets application will be one).  Given a URI, you
cannot tell from Content-Type whether that URI supports WebDAV, and
you cannot tell whether that URI accepts POSTs to submit new blog
entries - just to pick two widely used examples.

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.

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

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

It's an intersting question, but please don't get too sidetracked from
the (imho) more important question of ensuring that specific web
applications can connect to WebSockets resource whose URI is provided
by a third party, with a reasonable level of safety and security.

-- Jamie