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

The UPGRADE mechanism was a fine idea. Poor transparent proxy
implementations have killed its effectiveness.
-=R


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