Re: [RFC] CONNECT and use_ssl cache_peer

On 10.09.2012 13:08, Henrik Nordström wrote:
> 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.

I'm imagining a setup of:

  client TCP -> ConnStateData(BodyPipeProducer) -> Bump(BodyPipeReader,
'fake' ConnStateData(BodyPipeProducer) ) -> BodyPipe -> server-side

so that:
  * the bumped CONNECT tunnel can be the source of a whole pipeline of
requests (HTTPS, etc)
  * the original ConnStateData->Bump section of code retains all the
CONNECT semantics down to and including terminate 'server' connection
(aka Bump Node destructs) on end of CONNECT independent of what Bump ->
server-side does with the server-side connection.
  * when receiving a CONNECT we detect the right type of streams reader
to handle the data and allocate it:
    ** the Bump node could be Upgrade:TLS, Upgrade:WebSockets,
Upgrade:HTTP/2, SSL-bump, pass-thru tunnel or some future protocol

>
>> 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.
>

That other indication would be Content-Length or chunked encoding yes?
which currently are ignored, with some annoying results.

>> 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.

The gap is that chunking can be (and is!) implemented on the opaque
data stream after POST+Upgrade, GET+Upgrade, FOO+Upgrade - yet is
undefined and not implemented for CONNECT+Upgrade or plain CONNECT. The
prose describes CONNECT as having no body which implies there is nothing
to chunk, but in practice there is usually opaque data there to be
relayed same as for POST.

>
> 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.

It would have to be a separate flag/negotiation from any other method
yes. But I think the server 'cache' can still flag it for use across
subsequent CONNECT requests.

>
>> 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

Amos
Received on Mon Sep 10 2012 - 02:13:06 MDT