Re: workability (or otherwise) of HTTP upgrade

Greg Wilkins wrote:
> > What about:  3) Use another port?  I've seen that opinion voiced,
> > so I haven't signed up to the hybi list to voice it myself.  No
> > criticism of Web Sockets is intended or implied here, it's just a
> > concrete example of something which increasingly concerns me
> > regarding Upgrade.
> The problem with another port, is that the success rate of  opening an
> arbitrary port through firewalls is not that high.

Uptake is always a problem with new protocols.  I don't see how this
justifies breaking the security architecture of port 80 (by eliminating
media-type filtering).

> Thus if websocket was allocated it's own sockets, then there would
> still be need for a websocket over 80 protocol (eg like there is BOSH
> for XMPP).

Perhaps.  XMPP over BOSH looks like HTTP to me, though.

> I would like to see a dedicated port for websocket so that over time
> it could be opened as needed, but I think there will be a desire to
> function over 80 for some time to come.

Just because there's a desire for new protocols to work with existing
URLs, doesn't mean it's a good idea.  There's also a desire to keep
port 80 securable, which gets harder each time another dissimilar
protocol is factored in.  IMO, the latter desire outweighs the former.

> This could be done with some enhanced HTTP (eg SPDY), but I'm not
> sure if such a protocol would match all the features of websocket (eg
> improved data density), nor fit with your HTTP-like restrictions
> described below.

Most of the problems Web Sockets addresses, seem solveable to me by
adding a new method(s) to HTTP (say, IDLE).  I'm not convinced that
improved data density, at the expense of cacheability, results in a net
performance gain -- the way to improve performance is to reduce the
instances of communication over the network (i.e. caching).  Reducing
header overhead via reduced verbosity makes sense; eliminating headers,
thus forcing tunneled communications, does not.

> > It's perhaps fundamentally flawed for HTTP to be the handshake
> > mechanism for protocols that are not even remotely similar to HTTP.
> >  In this case, we have a half-duplex, request/response,
> > resource/representation protocol establishing a full-duplex,
> > asynchronous, opaque-bits-on-the- wire connection that's
> > fundamentally incompatible with the deployed architecture of port
> > 80 (caches, security gateways); and which nobody seems happy with.
> >
> > My suggested fixes to 9.8, based on the notion that HTTP 1.0, 1.1
> > and 2.0, and PTTH 1.0, are not "incompatible" protocols:
> >
> > "The 'Upgrade' general-header field allows the client to specify
> > which version of the communication protocol it would like to use,
> > if the server chooses to switch versions.  Additionally, the server
> > MUST use the Upgrade header field within a 101 (Switching
> > Protocols) response to indicate the version(s) being switched to.
> >
> > The Upgrade header field is intended to provide a simple mechanism
> > for transitioning from HTTP/1.1 to some newer, compatible
> > protocol...  This eases the difficult transition between versions
> > of compatible protocols by allowing the client to initiate a
> > request..."
> >
> > This opens a whole can of worms about what constitutes a compatible
> > protocol, instead of the current wording:  "The capabilities and
> > nature of the application-layer communication after the protocol
> > change is entirely dependent upon the new protocol chosen," which
> > seems like the sort of free-for-all that leads to unintended
> > security consequences.
> Indeed.  Is HTTP over SSL a compatible protocol? semantically yes, but
> it is fundamentally different on the wire.

It looks like HTTP to participants in the communication, gobbledygook
to others.  As opposed to another protocol which, when decrypted, isn't
remotely similar to HTTP.  So I meant semantically, as opposed to on-
the-wire; IOW, I don't see TLS as being germane to my point.

> Would this restriction also apply to protocols like SPDY that are
> enhanced HTTP-like protocols, but with additional features.

Solving the multiplexing problem with HTTP over SCTP seems like better
engineering to me.  The Web's continuing success has to do with the
shared-intermediary architecture that's been deployed for port 80.  I'm
opposed to any protocol meant for port 80 which precludes this option.
HTTP+TLS is *optional* tunneling.  Web Sockets and SPDY are *mandatory*
tunneling.  Caching scaled the Web, that success should be built upon,
not abandoned as obsolete (particularly absent any evidence indicating
this to be so).

> > My issue is whether it's overreaching to extend Upgrade from being a
> > versioning mechanism for HTTP, into a general-purpose protocol
> > tunneling mechanism.  Or securable.  Does a registry need to be
> > defined here, and if so, shouldn't there be some fidelity with the
> > notions of the media type and request/response architectural
> > paradigms?
> RFC2817 would appear to have gone beyond that already.

How so?  It's still request/response, and a user-agent may still be
configured to, for example, not render application/pdf even if it's
tunneled through a security firewall which ordinarily blocks PDF on
port 80.  Serving JSON as text/html is a known security problem, i.e.
context escaping.  If an HTML page sets this context, and port 80 is
used to fetch some JSON, how do I change the context if there's no
media type?  HTTPS, HTTP+TLS, XMPP over BOSH and so forth, don't have
this problem; whereas I don't see how Web Sockets avoids it without
being on its own port.

> >> So I'd ask the httpbis readers, are there any reasons you know of
> >> that would prevent Upgrade being used for websocket?
> >>
> >
> > Yes -- Web Sockets is fundamentally different from anything I'd
> > expect to see on port 80.  The fact that this is exactly what
> > Upgrade allows, even encourages with the proposed registry, gives
> > me the heebie-jeebies.
> And do you get similar feeling to think about using the CONNECT method
> to establish tunnels for arbitrary protocols?



Received on Tuesday, 30 November 2010 00:54:27 UTC