Re: HTTP2 server-side stream creation

On 11/07/2015 12:43 a.m., Cory Benfield wrote:
> On 10 July 2015 at 13:06, Amos Jeffries wrote:
>> I think this extension should mean only that the sender (normally
>> client) is agreeing to be a server in the context of this whole
>> connection. The recipient may then perform stream initiation as per the
>> specifiation for how clients initiate streams to a server.
> 
> So it seems like this would be fundamentally different to what I'm
> proposing, unless I've misunderstood you. Your proposal is basically
> entirely isomorphic to the Reverse HTTP draft, allowing the client and
> server to swap over. That still leaves us in the situation where a
> server that wants to become a client (to deliver a message) is out of
> luck. What it doesn't allow is for both endpoints to be initiating
> streams by sending requests simultaneously. Is that understanding
> correct?
> 


I think you have misunderstood me.

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.


Lets put it this way:
 If a client has *not* indicated clearly that it is capable of becoming
a server on the connection, how would the original server be able to be
a client ?

The original server needs to assume that all clients are traditional
one-way clients unless they state willingness to be bi-directional /
reverse HTTP / whatever. Anything else leads to breakage.

The original client can safely assume bi-directional servers. It simply
wont get any requests from the ones that actually aren't. Which is fine.


NP: that model could work in both HTTP/2 and HTTP/1.1 if one does not
use long pipelines in the 1.1. Though getting 1.1 software to do it at
all this late stage of HTTP evolution could be difficult.


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.

Amos

Received on Friday, 10 July 2015 17:58:14 UTC