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

Yes.

-Eric

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