Re: [hybi] Different server semantics of CONNECT

[John Tamplin <[e-mail]>]

On Mon, Dec 6, 2010 at 7:19 PM, Henrik Frystyk Nielsen
<[e-mail]> wrote:
> I would like to second Roy's observation that redefining HTTP semantics is a non-starter.
> The main goal should be to settle on a handshake that works and has a high probability of
> surviving the IETF process which basically means that it has to follow HTTP semantics. I
> haven't seen any persuading arguments that would justify this WG to go beyond its
> charter and attempt to change HTTP directly. Traditionally, arguments citing interop
> problems with particular existing implementations is not sufficient for a spec to change,
> especially not when it is as widespread as HTTP. I don't think this in any way precludes the
> WG from coming up with a reasonable, lightweight yet robust handshake so I would
> encourage the discussion to continue but also to constrain itself to the boundaries put
> forward.

First, I am not sure that the CONNECT method is well-enough specified
that anything could be considered changing it.  RFC2616 only has this
to say:

> 9.9 CONNECT
>
> This specification reserves the method name CONNECT for use with a proxy that can
> dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

It doesn't even talk at all about what is acceptable in the request
line, headers, responses, etc.  The only draft which ever made any
attempt to specify it (as far as I am aware) -
http://tools.ietf.org/id/draft-luotonen-web-proxy-tunneling-01.txt -
expired in 1999 (!), so it seems to be stretching the facts to call
that an active spec.

Second, I think it is arguing over semantics to say that the proposed
use of CONNECT does not fit this definition.  The 14 mentions of
"proxy" in the HTTP spec don't really shed any light on whether an
HTTP server acting as a gateway to WebSocket applications could be
considered a proxy, but certainly seems reasonable to consider it so.
Even if not, I would argue that refining the terminology in 9.9 to
clarify "proxy" should not be considered changing the HTTP spec, when
it is so woefully underspecified at present.  Clearly, the intent of
WebSocket is to setup a message-oriented tunnel between the client and
the server, so it seems that part fits.

It seems that those so fundamentally opposed to using CONNECT are
setting up a no-win situation.  If we can't use GET+Upgrade because
real-world implementations never bothered to implement it because it
wasn't actually used, and we can't use CONNECT because it is deemed to
be in violation of the HTTP spec, then where does that leave us?  We
can use a dedicated port, in which case WebSockets will not be usable
in the near future for anyone behind a configured proxy (ie, most
corporate environments and some home ones), or we can use some other
hack which has its own problems like POST with chunked encoding in
both directions.

Do you just want to kill WebSockets so we can stick with Comet/etc?
Is that any less abusive of existing HTTP infrastructure?

-- 
John A. Tamplin
Software Engineer (GWT), Google