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

[Greg Wilkins <[e-mail]>]

Willy,

if we insist on trying to fail on infrastructure that might work (even if it
doesn't understand
websocket), then I think this is indeed an good proposal.

But I fundamentally do not agree with the premise that we should try to fail
simply
because our infrastructure is working, but not the way we want it to work.

I don't see what this buys us - say we do establish that every bit of
infrastructure between UA and server has been replaced with something shiny
and new that understands websocket - does this mean that we no longer need
to monitor the health of the connection and just assume that everything will
magically work?

No!

Networks can and do fail - even shiny new ones that understand websocket.
And they can fail in all sorts of nasty ways - black holes, repeated frames,
horrible latencies etc etc.

No matter what, any reasonable websocket based application is going to need
something to monitor the health of the connection and to make a continual
assessment of "it's working" vs "it's not working".     Even if we could
knowing that all intermediaries are websocket aware does not help this in
any way, shape or form.  And we can't know if all intermediaries are
websocket aware: your suggestion will indeed detect a class of non-ws
intermediaries, but there will also be other ones that are semi-HTTP away
but don't respect Connection:close or that operate at TCP/IP level etc.

Currently the protocol is designed to try to fail and only work if
everything is perfect.
I think we should instead make it try to work and fail only if there is a
problem.

regards











On 22 July 2010 08:52, Willy Tarreau <[e-mail]> 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.
>
> The client then gets an empty response without the in-protocol HELLO
> message and knows that an intermediate is in the way and is not compatible.
>
> The only way for such a response to pass unmolested to the client is
> for intermediates to have a proper understanding of the 101/Upgrade
> mechanism which implies that any data after the empty line is to be
> tunnelled, despite Content-length: 0.
>
> It also has the nice advantage of being compatible with HTTP, which
> means that ISPs making use of transparent proxies will have no problem
> adding reliable cache-bypass rule which relies on the Upgrade: header.
>
> Any thoughts ?
>
> Willy
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>