Re: [hybi] #1: HTTP Compliance

[Roberto Peon <[e-mail]>]

On Tue, Jul 20, 2010 at 11:47 PM, Ian Hickson <[e-mail]> wrote:

> 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.
>
>
I fully expect that we'll end up with multiple websocket "sockets" per tab,
and we typically end up with many tabs.
This is true even if going to only one large site. For instance, it is
fairly normal to have both corporate and personal email and calendering open
at all times.
If each websocket is its own TCP socket, we'll face a drastic increase in
the number of connections from everyone.
Worse, these connections won't go away, they'll send junk bytes all the time
(keep alives), they'll be unable to go to the same server if one is using
loadbalancing, they'll have more than an order of magnitude greater chance
to overload NAT tables, they'll make DST caches in the kernel less effective
due to dilution (for smaller servers), etc.

Each and every of these is a good reason that the complexity is warranted.
I have some "small" experience with ensuring that things can serve at-scale.
There are very good reasons that I'm concerned about websocket scalability.

As for complexity! At worst, you have flow control and multiplexing.
 Multiplexing involves a unique ID per channel. Flow control involves
sending periodic updates telling the other side how much it can send safely.
Of course you also need to have a table in which you do a lookup to see that
there is already a connection for that domain, including a reference to
that connection. None of this is difficult, even in concert.

-=R

>
> > > 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.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>