W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: workability (or otherwise) of HTTP upgrade

From: Greg Wilkins <gregw@webtide.com>
Date: Fri, 26 Nov 2010 23:55:58 +1100
Message-ID: <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com>
To: "Eric J. Bowman" <eric@bisonsystems.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
On 26 November 2010 18:03, Eric J. Bowman <eric@bisonsystems.net> 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.     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).

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


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

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


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

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


cheers
Received on Friday, 26 November 2010 12:56:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT