- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Fri, 10 Jul 2015 20:41:49 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> On 10 Jul 2015, at 18:57, Amos Jeffries <squid3@treenet.co.nz> wrote: > I think you have misunderstood me. I suspected as much! > The one-way property is only at the outset before the initial TCP > connection client has sent its NTP=1 flag/setting to the server. Once > that arrives at the server both parties are aware that the client is > willing to also be a client+server. > > One the server has that awareness, simply sending a request down the > connection to the client is enough to signal its capability of being a > client+server as well. > > Then everything is bi-directional. Right, so the assertion is that this needn’t be a negotiated extension, just an offered one? That feels reasonable to me. > I am looking at this from a proxy perspective. Our likely use case is > for the "sibling" relationship between proxy caches. Serving users who > deliver a request to one for data which is in the other. > > Today we do this with 2 TCP connections, one for each direction of > flow. Sometimes so much crossover happens that we hit socket limits on > how many inter-proxy TCP connections can be used. It would be a bit more > efficient to be able to bi-directional those connections and reduce the > needed sockets. If you think that proxies can gain benefit from this proposal, I’d love some suggestions for additions to the draft. You know the intermediary case a lot better than I do!
Received on Friday, 10 July 2015 19:42:17 UTC