Re: HTTP2 server-side stream creation

> Am 10.07.2015 um 10:47 schrieb Cory Benfield <cory@lukasa.co.uk>:
> 
> On 10 July 2015 at 09:13, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>> What would be the minimal behavior a conforming endpoint needs to exhibit? Say a client talks h2 with just this extension. Is there anything the server can assume about the nature of the streams it can open against the client? Does the client need to answer incoming HTTP requests? Against which authority? If left unspecified, how is this extension then used?
> 
> I think this is the critical question to answer. I think the server
> can assume that the client would answer incoming HTTP requests, but we
> definitely have to decide how to signal the client authority.
> 
> This cannot be negotiated in the SETTINGS frame because with only 32
> bits available for the settings value a client would be pretty limited
> in what it can offer. That really leaves us with either using a HTTP
> header field, piggybacking on a different frame type, or introducing a
> new frame type. I think using a header field for this is a bit
> unpleasant (it smacks of the weirdness of Reverse HTTP[0] which I
> don't particularly love), though it could work. I don't think there's
> a good frame type to piggyback on, so the other option would be to
> have a new frame type that is used in this case. That feels like the
> best option: the client essentially emits a frame that says "I am
> happy to receive requests for authority X".

A bit more thinking: this whole server-side creation can only work when
there are *no* concentrating intermediates involved, right? Where would a 
proxy forward the server stream to?

Otherwise clients would need to allocate some sort of name at proxies
and then proxies need to inspect new HEADERs for matching :authority and
it gets only uglier from there...

Or am I missing something?


<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Friday, 10 July 2015 14:13:08 UTC