Re: Concepts to improve Http2.0

> On 29 Jul 2016, at 07:35, Wesley Oliver <wesley.olis@gmail.com> wrote:
> 
> Using a header continuation frame could be used as a hack, if the browser implementation allowed,
> which is an alternative to the javascript page redirect while pushing content on another stream, as I proposed in
> the document below:
> https://docs.google.com/document/d/1xGY4GycBMt4zyCoJpzoIZrlLOs1bwaRVBfPE9aXdbyE/edit?usp=sharing <https://docs.google.com/document/d/1xGY4GycBMt4zyCoJpzoIZrlLOs1bwaRVBfPE9aXdbyE/edit?usp=sharing>
I am strongly opposed to repurposing CONTINUATION in this way. Doing so requires a negotiated HTTP/2 extension because it changes the semantics of an existing frame, so it has just as much work as doing something that doesn’t overload CONTINUATION.

> Concept on how I envisage the modified http 2.0 state to work.
> 
> Request
> Response Headers -  for the current request.
> Data Frame - Requested pages.
> 
> Optimistically send ENDHEADERS ,STARTHEADERS with the 
> Response Headers - Output 404 and because this is not a continuation headers frame, it reset the stream state implicitly as it is the first headers frame.
>                               The browser also then knows to reset its internal workings such that it can render a new response body for the same url.
> Data Frame - Start, to mark difference between old header response body and the new header response body.
> End Stream.

This flow requires negotiation. This is because currently a second HEADERS frame after the initial response header represents trailers, and therefore must carry END_STREAM (either directly on the HEADERS frame or on the last of its CONTINUATION frames): it does not “reset the stream state implicitly". Most implementations will enforce this restriction, and so you’d need a negotiated extension (as per RFC 7540 Section 5.5) to get this to work. Probably this extension would define a new HEADERS flag (START_AGAIN) that simply transitions the stream back to a pre-data-sending state.


Cory