Re: [hybi] WebSocket, TLS and intermediaries

[Willy Tarreau <[e-mail]>]

On Wed, Jul 21, 2010 at 02:13:54AM -0700, Maciej Stachowiak wrote:
> HTTP pipelining is a clear example of a feature that is largely blocked by intermediaries not being updated enough.

It's not always a matter of not being "updated enough", but a matter of
"not always being implementable at all at a reasonable cost". Supporting
pipelining on intermediaries can require a very complex software architecture
with complex resource management to support multiple requests in flight,
sometimes for little added value. What is important though is that pipelined
requests all get processed in the correct order just as if they were not
pipelined. But are their still that many products that are incompatible
with pipelining ?

> When a protocol feature requires client or serve updates, then often it can be deployed incrementally when only a subset of clients or servers is updated, since they can come up with a way to signal to each other.

This is what was done with early WS implementations and multiple client and
server implementations have existed, BTW.

> However, if it is possible for intermediaries to get in the chain completely transparently, without any way for the client or server to know they exist, then it's quite difficult, perhaps impossible to come up with a reliable signal. In my opinion, to the extent we support intermediaries, the design should require at least one of the client or server to be explicitly aware of the intermediary.

Not necessarily, if we rely on standards and the intermediaries support those
standards, there is no need for the ends to know about them. Neither your
client nor your servers are aware of the number of routers and firewalls
in the chain because the service they offer relies on well established
standards and they act transparently. The same must be true with intermediaries
here. By using a standard HTTP handshake, standard-compliant intermediaries
can work without either of the client or server being aware of it. But if we
use non-standard derivative of well-established standards, of course we're
impacted a lot by standard-compliant intermediaries.

> We should not support magical transparent intermediaries where neither the client nor server has
>   an obvious way to detect its existence; in fact we should design the protocol to prevent such intermediaries from being created.

I disagree here. Intermediaries will be created whatever efforts you put to
try to make them fail. They will exist because people who deploy them need
them, and the quality of their implementation is no problem for them. The
dirtier we proceed, the uglier they will look like and the poorest the
resulting quality of service for the client.

There must not be "magical transparent intermediaries", there must be some
natural and implicit support for standard-compliant intermediaries so that
any new requirement can happen within a standard, and involves no "magics".

Regards,
Willy