Re: [hybi] Proposal for a clean way to detect non-HTTP compliant transparent proxies

[Jamie Lokier <[e-mail]>]

Willy Tarreau wrote:
> 
> I've just thought about a way to fix the initial handshake so that it
> works with proper HTTP-compliant implementations but still fails through
> non-compliant transparent proxies.
> 
> Let's have the client send the initial handshake request to the server.
> This handshake is only made of HTTP headers. The client completes the
> request with "Connection: close" so that a transparent intermediate
> does not wait for a possible second request in case it does not understand
> the upgrade response :
> 
>    GET /xxxx HTTP/1.1
>    Upgrade: WebSocket
>    Connection: close
>    ... ws headers ...
>    ...
>    \r\n
> 
> The server will send :
> 
>    HTTP/1.1 101 Swithing protocols
>    Upgrade: WebSocket
>    Content-length: 0
>    Connection: close
>    ... ws headers ...
>    ...
>    \r\n
>    any-form-of-hello-message (eg: the server's protocol version)
> 
> That way, if a transparent proxy does not have explicit support for 101,
> it will only forward the headers with an empty body (CL: 0) and close the
> connection towards the client.

I think this won't work.  RFC2616 (HTTP 1.1):

   "Proxies MUST forward 1xx responses, unless the connection between the
    proxy and its client has been closed, or unless the proxy itself
    requested the generation of the 1xx response."

It's not spelled out explicitly, but the expectation is that proxies
forward 1xx responses generically, and then forward the next response.

If the proxy doesn't know how to handle 101 responses, then it may
simply forward the 101 as a generic 1xx, and then try to forward the
*following* bytes as a HTTP response.

I would expect proxies to ignore Content-Length in 1xx:

   "1. Any response message which "MUST NOT" include a message-body (such
       as the 1xx, 204, and 304 responses and any response to a HEAD
       request) is always terminated by the first empty line after the
       header fields, regardless of the entity-header fields present in
       the message."

In other words, a relatively stupid proxy, but which is aware of the
1xx rule, will not close the connection, and will treat the hello
text and subsequent bytes as a HTTP response to modify and forward.

There's some discussion on another list about using a 1xx response to
indicate "request is being processed", for when the processing is slow
to produce a response.  The fact that is being taken seriously
suggests that at least some deployments do forward 1xx messages in the
way the standard requires.

-- Jamie