Re: WebSockets negotiation over HTTP

On Fri, 2009-09-04 at 01:44 +0000, Ian Hickson wrote:

> > One very real example of this would be the web server or an fully
> > WebSocket capable intermediary sending back bytes
...
> > example #1 suppose there was an intermediary translating websockets-over-http
> > to websockets-port-81 which used HTTP to format said headers of confirmation.
>
> Here is the problem I have with this: Why would we suppose the existence
> of such an intermediary? Why would anyone ever implementa
> WebSocket-specific proxy?

Welcome to the internet :). Seriously, Why would we suppose the
existence of an intermediary that intercepts and MITM's SSL connections?
Or HTTP - its even got a defined proxy facility, there is no need to
take over and insert different behaviour, is there?

We *should* assume that firewall vendors and ISP's will do arguably
insane things, because they have time and again in the past.

> > example #2 is where the traffic is processed by an HTTP-only
> > intermediary which sees the 'Upgrade:' header and flags the connection
> > for transparent pass-thru (This by the way is the desirable method of
> > making Squid support WebSockets).
> >
> > Being a good HTTP relay it accepts these bytes:
> > HTTP/1.1 101 Web Socket Protocol Handshake
> > Upgrade: WebSocket
> > Connection: Upgrade
> >
> > It violates HTTP by omitting the Via and other headers your spec omits to
> > handle. And passes these on:
> > HTTP/1.1 101 Web Socket Protocol Handshake
> > Connection: Upgrade
> > Upgrade: WebSocket
> >
> > then moves to tunnel mode for you.
>
> Why would it violate HTTP in all the ways you mention? If it goes to such
> extreme lengths to have transparent pass-through to the point of violating
> HTTP, why would it then go out of its way to reorder header lines?

Because sysadmins do this! Don't ask us to justify the weird and
wonderful things we run into. Nearly daily we have users asking for help
doing similar things in #squid.

> From my perspective, such a proxy would raise all kinds of alarm bells to
> me, and I would be _glad_ that the connection failed. If it didn't, I
> wouldn't be sure we could trust the rest of the data.

Again, welcome to the internet :P. Seriously, if its not digitally
signed, you *can't* trust the rest of the data.

> The MITM isn't the WebSocket client. In this situation, it's a
> (non-compliant, since it forwarded by-hop headers) HTTP proxy. What's
> more, in this scenario the server isn't a WebSocket server, either, it's
> an HTTP server. So what Web Socket says is irrelevant.

Note that there are *still* HTTP/1.0 proxies in deployment that don't
know about hop by hop headers.
...

> > > WebSockets, even when initiating the connection by talking to an HTTP
> > > server and then switching to WebSockets, isn't layered on HTTP. It's
> > > just doing the bare minimum required to allow the HTTP server to
> > > understand the request and get out of the way. Once the handshake is
> > > complete, there is no HTTP anywhere on the stack at all.
> >
> > Its not doing the bare minimum.
> >
> > The bare minimum would be to accept the valid HTTP transforms which the
> > Internet _will_ perform on the handshake. Discard those useless transforms and
> > validate the handshake status line.
>
> The "bare minimum" is the least amount of processing possible. What you
> describe is _more_ processing, not less. Therefore it's not the minimum.

The bare minimum would be to just start the tcp connection with
'websocket/1.0\r\n'

Stop pretending to be HTTP: use port 80.

Our whole point has been, if you want to "Use HTTP Upgrade", Do It
Correctly.

If you want to "Use port 80", just do that.

> On Thu, Jul 30 2009, Henrik Nordstrom wrote:

> > But for 2 you need to use HTTP, which essentially boils down to defining
> > that one may switch a webserver to use WebSockets by using the HTTP
> > Upgrade mechanism as defined by HTTP.
>
> I understand that you disagree with my interpretation, but my
> interpretation is that this is exactly what the spec does already.

At this point I think we need to go to the HTTP-WG and discuss further.
Most of us are already there...

> > > > 5) Specific mention is made to ignore non-understood headers added
> > > > randomly by intermediaries.
> > >
> > > So long as that happens after the handshake, that's ok, but we can't
> > > allow that inside the handshake, it would allow for smuggling data
> > > through,
> >
> > If having this view then you CAN NOT use HTTP for the Upgrade handshake,
> > and MUST use another port and other protocol signatures.
>
> IANA expert review has informed me that I must use ports 80 and 443, so
> there I don't have a choice here.

Whats the message id & what list? I'm extremely happy to jump into that
conversation.

-Rob