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

Jamie Lokier writes:

> noah_mendelsohn@us.ibm.com wrote:
>  If the server (I.e. the same software that would have 
> > processed the Web socket upgrade) chooses to, it can respond with 
metadata 
> > explaining that this is a Websocket resource, perhaps providing 
> > information about its purpose and correct use, etc.  The means for 
> > returning that metadata might be along the lines of [1].  That 
> > discoverability seems to have some value. 

> Hey, I like that idea.  Wish I'd thought of it :-)

I can't honestly tell if you're agreeing with me or gently pulling my leg. 
 If the former, then this is a reason to use an http-scheme URI.  Thanks.

Noah

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








Jamie Lokier <jamie@shareable.org>
08/20/2009 03:01 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     Ian Hickson <ian@hixie.ch>, hybi@ietf.org, Mark Nottingham 
<mnot@mnot.net>, URI <uri@w3.org>
        Subject:        Re: [hybi] [Uri-review] ws: and wss: schemes


noah_mendelsohn@us.ibm.com wrote:
 If the server (I.e. the same software that would have 
> processed the Web socket upgrade) chooses to, it can respond with 
metadata 
> explaining that this is a Websocket resource, perhaps providing 
> information about its purpose and correct use, etc.  The means for 
> returning that metadata might be along the lines of [1].  That 
> discoverability seems to have some value. 

Hey, I like that idea.  Wish I'd thought of it :-)

For round-trip reduction I favour being able to try an upgrade
request, with your own optional headers, and have the server reject it
if it doesn't see what it wants, perhaps referrring to the information
you've described.  It also leaves the door for servers to respond with
different protocols depending on the request - in the same way as SSH1
and SSH2 are negotiated, for example, without needing extra round-trips.

That looks a *lot* like HTTP negotiation, and people are very
familiar with that.  Servers have good support for it too.

> Web socket endpoints are not documents (or "Information Resources"
> [2] in the language of AWWW), suggesting that new schemes are indeed
> appropriate;

I agree.

A comet server on http://cometd.org.example/cometd.cgi?protocol=bayeux
(example may not be realistic) is not a document in any useful sense
either.  Where are we going with this?  Should that become a legacy
hack?  Should we have a different scheme for all
"protocol-over-HTTP-misused-as-a-transport"?

> 2) (happy accident) 

> I suspect the choice of an HTTP-compatible handshake was made to get
> through firewalls,

I suspect it was so that it could connect to random servers and get a
useful error message if they don't support WebSockets (that has been
explained on the hybi list), and to connect to servers which are
handling HTTP on the same port.

For getting through firewalls - including ISPs who don't firewall but
are running intercepting proxies on port 80 - I think it's basically
going to fail at that because it doesn't consider proxy issues at all
- and because UPGRADE has never been deployed (as far as I know).  But
to be honest I don't know if it'll fail as much as I think in the real
world without measurements from a wide range of internet locations.
I'm not the only person who thinks so, though.

-- Jamie

Received on Monday, 24 August 2009 20:17:53 UTC