On Wed, 19 May 2010, Jamie Lokier wrote:
> >
> > If we want to support multiple subprotocols at once, we can do so 
> > quite easily by just making the subprotocol list be comma-separated. 
> > Would this be a good idea?
> 
> I think it is a good idea, although there is a risk of low-quality 
> server but significant implementations matching a literal string, 
> breaking when other values are added to the comma-separate list, and 
> therefore making it impossible for clients to actually use the 
> capability.

Yeah, though since that bug would be specific to implementations of 
particular subprotocols, it would be pretty localised to individual 
communities. That's probably an acceptable problem.

I've added this to the spec for now.

   http://html5.org/tools/web-apps-tracker?from=5172&to=5173


> But assuming the comma-separated list did catch on, a consequence of 
> that would be the "below the API" part of WebSocket would have a place 
> to add its own distinct entries to the comma-separated list, for 
> recognition by the other side as transport option requests (such as 
> compression, etc.), safe in the knowledge it wouldn't break negotiation.
> 
> (Separate headers would be much cleaner for that, though).

I don't see why we wouldn't just use separate fields for that. No need to 
overload the subprotocol field.


> > >    - Trying a HTTP-based protocol if WebSocket is unavailable (ditto)
> > 
> > That wouldn't work anyway because the WebSocket object isn't the same 
> > object as the XMLHttpRequest object and they therefore create entirely 
> > different connections.
> 
> Just being different objects is not technical reason for different 
> connections. Separate XMLHttpRequest objects have no problem sharing 
> connections. There is no technical reason why a WebSocket object could 
> not do the same, just as easily.  Especially in browsers which routinely 
> do this!

I guess. I'm not convinced it's a good idea though.


> > In any case, why wouldn't you know that Web Socket is available? I 
> > don't understand why you would guess that it is and then find it 
> > isn't. You need a URL to connect to a Web Socket, why would you make 
> > up a URL without knowing whether it'll work?
> 
> Earlier in this thread, in a reply to you, we already gave an example. 
> It was the social networking client that talks to numerous de facto 
> standardised but different WebSocket protocols that the user shouldn't 
> have to know about.
> 
> Basically because autonegotiation is more user-friendly, both in terms 
> of users having to be given and enter fewer details, and in terms of 
> telling the user what went wrong if things didn't work out.
> 
> As you noted, people don't always pass around URLs - they often pass 
> around just a domain name, or a truncated URL that doesn't include the 
> "http:" prefix.
> 
> I would agree if it were _complicated_ to do, but we are talking about 
> really trivial stuff here.  Trying one thing, then trying another, is 
> already handled by the handshake, and it is utterly trivial to do from a 
> script.  It's so easy that it's hard to see why any random web developer 
> wouldn't use it whenever it seemed like a good idea.
> 
> It seems obvious to me that countless Javascripts will do exactly that.

I could see trying multiple WebSocket protocols over one connection, but 
trying to try both HTTP or WebSocket connections, not to mention any other 
protocols the servers might provide, seems like massive complexity for 
negligible gain overall.


> > This can be supported entirely in Web Socket if we want to do that. 
> > Currently, it's not clear that supporting this is even desireable, due 
> > to the UI issues with doing so.
> 
> (On that topic, how do you propose to get through a proxy on port 443 
> that needs proxy authentication before it passes a CONNECT request?)

I guess the UA would have to use the existing (suboptimal) UI for proxy 
auth. It's not a good situation to be in; I wouldn't recommend it.


> > WebSocket and HTTP are different protocols. Reusing the connection 
> > makes as much sense as reusing the connection of an FTP connection 
> > attempt to do an HTTP connection attempt.
> 
> This is different.  Both WebSockets and HTTP requests are transient in 
> many cases.

FTP is more transient than WebSockets. WebSockets is intended for 
connections that just stay open. It's not intended for transient use. It's 
not at all designed for transient use. It will do poorly when used for 
transient use.


> If FTP was also transient, and it shared the same port with 
> HTTP, and many servers especially those designed for high performance 
> implemented both together, and many clients implemented both, then of 
> course it would make sense to _permit_ connection reuse between them, 
> without _requiring_ any implementation to do so.

I think it would be pretty silly even in those cases, personally. Reusing 
connections amongst multiple protocols is simply asking for bugs. The 
benefits are minimal and the costs are high. If you want to do multiple 
things on a connection, use a protocol that supports all those things, 
don't try to switch back and forth between protocols.

(By extension, I think the Upgrade mechanism in HTTP isn't a particularly 
good idea. The number of times the mechanism has been used to great 
success on the Web somewhat supports my position on this, I think.)


> There is a much stronger case for reusing a WebSocket connection after a 
> gracefully close that puts it into some kind of idle state.  That's 
> because users follow links every few seconds - and therefore WebSocket 
> scripts in ordinary pages will connect and disconnect from the same 
> server and port every few seconds in the current model.

What use cases are you imagining that have Web Sockets used in such 
scenarios? None of the intended use cases even remotely resemble this. Web 
Sockets is intended for use on pages that are long-lived. It's quite 
possible that there are use cases on short-lived pages also, but they 
probably need their own protocol, optimised for those cases (e.g. HTTP and 
the text/event-stream EventSource mechanism). WebSockets isn't trying to 
be everything for everyone, it's just trying to address the specific use 
case of trivially-implementable long-lived TCP-like connections for Web 
browsers.


> Making it optional for both sides adds *zero* complexity for authors who 
> don't do it. I am not seeing how you can think it makes any difference 
> to them.

Clients have to support it. This means implementation cost, testing cost, 
and bug-fixing cost. It then propagates to documentation, which means 
reference costs, tutorial costs, etc. This further means that authors will 
see the feature in documentation. This leads to cognition costs when 
learning the material, information retrieval costs when distinguishing 
whether something is relevant or not when debugging, and communication 
costs when discussing the feature with others, e.g. when determining 
whether the feature is relevant to the question someone is asking. Then 
there's the cost of maintaining code that someone else has written that 
_does_ use the feature, there's the cost of debugging browser bugs when 
the feature is misimplemented and interacts even with code that doesn't 
use the feature, and finally there's the cost of implementing the feature 
on the server side once it makes its way onto check-mark lists of features 
that every web developer customer wants to support.


> Seriously, how do you imagine it affects them?

Optional features are a lie. Nothing is really optional in a platform like 
the Web's -- the only way a feature can be "free" is if it doesn't exist. 
This is why we have to justify everything we add, and make sure it's on 
the right side of the 80/20 line.


> > who would have no idea why their WebSocket servers were suddenly 
> > receiving random HTTP requests and vice versa.
> 
> That's a function of connecting to the wrong type of server already, and 
> it's already dealt with by the spec'd negotation, which the wrong type 
> of server handles already by design.  Nothing new there.

If we supported connection reuse and there was misconfiguration, then the 
kinds of failure scenarios would be much more varied than they are now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'