Re: HTTP2 server-side stream creation

When I first asked people here about server-side streams, the proposed mechanism was that the client opens a "send me push promises on this one and no answer" stream.

Such special streams that do not expect a reply would be suitable to announce service endpoints.

Assume the client wants to serve http. It opens a stream X with special flag and a header like ":service http". The server then opens a stream Y to this service by a push promise on X. 

If the client no longer wants to serve http, it RST_STREAMS X. 

This should make it easy for intermediaries to make informed decisions about routing such streams or even announcing services themselves.

//stefan


> Am 10.07.2015 um 21:41 schrieb Cory Benfield <cory@lukasa.co.uk>:
> 
> 
>> 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 Saturday, 11 July 2015 08:05:12 UTC