Re: workability (or otherwise) of HTTP upgrade

Greg Wilkins wrote:
> 
> The hybi/websocket protocol, as currently proposed, has a handshake
> mechanism that is roughly based on the HTTP upgrade mechanism.
> Progress in the hybi/websocket mailing has ground to a halt because we
> appear unable to get a clear consensus between the two advocated ways
> forward:
> 
>  1) Make the "roughly based" HTTP upgrade mechanism a fully compliant
> HTTP upgrade.
>  2) Move away from HTTP upgrade and use another mechanism (potentially
> CONNECT or SSL extensions)
> 

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.

> 
> My understanding is that Upgrade was included in HTTP for precisely
> the reason that Websocket wishes to use it - ie to take an existing
> HTTP connection and to upgrade the protocol run over the connection to
> something with different capabilities than HTTP.
>

This is my understanding, also.  The problems hybi has run into make me
question whether this is at all wise -- much easier to secure port 80 if
Internet Media Types are required to be exposed in some sort of header,
using the request/response paradigm.  Having some notion of a processing
model expressed in a header externally from the data dates back to
Gopher; using media types enabled the proliferation of intermediaries
based on the resource/representation paradigm.

Shouldn't a line be drawn between what's appropriate for port 80, and
what constitutes an entirely different protocol?  Or is the intent of
Upgrade to deprecate registering new URI schemes in favor of a registry
of HTTP tokens?

> 
> If websocket is unable to securely use Upgrade, then there must be
> some fundamental flaw in Upgrade that should either be fixed in
> httpbis (if allowed by the charter).   If Upgrade cannot be fixed,
> then perhaps httpbis needs to somehow deprecate the mechanism and we
> can look together for alternatives?
> 

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.

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?

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

-Eric

Received on Friday, 26 November 2010 07:04:17 UTC