Re: Concepts to improve Http2.0

Hi,

I am hearing you Cory Benfield, the simple idea of header with START_AGAIN,
would be a simple enough extensions to the http 2.0 functionality
to achieve this outcome.

I see that the documentation say nothing about how the negotiation is to
happen.


5.5 <https://tools.ietf.org/html/rfc7540#section-5.5>.  Extending HTTP/2


   This document doesn't mandate a specific method for negotiating the
   use of an extension but notes that a setting (Section 6.5.2
<https://tools.ietf.org/html/rfc7540#section-6.5.2>) could be
   used for that purpose.  If both peers set a value that indicates
   willingness to use the extension, then the extension can be used.  If



I would envisage the following negotiation.

As per the tradition of http 1.0 we can just add an additional
request-header-field
to indicate support for START_AGAIN and then also added frame-setting for
this.

The reasons for it being in the request-header-field,
is the server needs to decided weather or not to buffer the response
immediately.
Especially for the first request on a connection to a new ip(domain).
Otherwise it would have to wait for the settings frame communication to
have proceed first,
which then introduce latency for client side and would result in the server
having to block
before it could response, clearly a degradation of performance.


The browser would then additional communicate the HTTP2.0 setting frame
support
for the entire connection life span and then upon confirmation stop
adding the request-header-field START_AGAIN support header.

Would the negotiation describe above be found acceptable?

Kind Regards,

Wesley Oliver






On Fri, Jul 29, 2016 at 9:28 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

>
> 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
>
>
> 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
>



-- 
-- 
Web Site that I have developed:
http://www.swimdynamics.co.za


Skype: wezley_oliver
MSN messenger: wesley.olis@gmail.com