Re: [RFC] CONNECT and use_ssl cache_peer

sön 2012-09-09 klockan 21:34 +1200 skrev Amos Jeffries:

> Henrik and I seem to disagree on this being a good idea being plugged
> into BodyPipe. But as I see it BodyPipe is where Upgrade, WebSockets and
> SSL-Bump should be happening in a node which internally "receives" the
> tunnel connection and acts like a ConnStateData reading out of the tunnel.

I am open for discussion on how it should fit, but initial reaction is
that there may be too much http semantics in the message model there to
fit well.

> When going DIRECT we have to assume the CONNECT is infinite length and
> handle as per now with closures.

You always have to assume that unless there is some other indication.

> But ... I see a potential gap in the RFC texts that when communicating
> between two proxies we can do one of several methods (Expect-100 or peer
> OPTIONS) to negotiate chunking support for any data the CONNECT has
> following it.

Not sure there is a gap, but I see your point. The data of a CONNECT is
not the message body, not more than the data following an Upgrade
handshake is.

There is not much negotiation taking place in CONNECT. Any extensions
has to be enabled by configuration. The 1.1+ protocol cache which can be
used to negotiate chunked encoding in requests for other methods is
useless for CONNECT as we cannot expect HTTP/1.1 servers to accept
CONNECT with transfer-encoding.

> Thus keeping the connection between the peers (only)
> re-usable after the CONNECT is finished. So long as the transformation
> (chunked encoding) is stripped away at the recipient proxy this does not
> introduce problems to the transported end-to-end data stream.

Yes...

Regards
Henrik
Received on Mon Sep 10 2012 - 01:08:21 MDT