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
