Re: Some HTTP 2.0 questions

On Wed, Dec 4, 2013 at 11:31 AM, Mark Watson <watsonm@netflix.com> wrote:

> Hi everyone,
>
> I recently reviewed the HTTP 2.0 draft. There are three things I expected
> to see that weren't immediately obvious how to achieve. Apologies if there
> have already been long discussions on these - feel free to point me at the
> archives if that is the case.
>
> (1) Canceling an HTTP request (e.g. if the client decides it no longer
> needs a requested resource). This is a pain to do with HTTP1.x, requiring
> the connection to be closed, losing all pipelined requests and incurring a
> new TCP connection establishment delay. I assume one could close a stream
> in HTTP2.0, canceling all requests on that stream. Does this mean that for
> individual control of HTTP requests one must ensure each response is on its
> own stream ? How does the client ensure that ?
>

you can cancel an individual transaction with a rst_stream::cancel. In
HTTP/2 parlance each transaction is on its own stream (and multiple
multiplexed streams make up the connection which subsumes the old pipeline
techniques.. each has its own stream ID).. streams are not reused as there
are plenty of integers available :).. This cancel is done all the time in
the early implementations of http/2 and spdy and the ability to do this
without terminating the connection is imo one of the under-appreciated
improvements of http/2.


>
> (2) Receiver modification of stream priority. The client may have
> (changing) opinions about the relative priority of resources. The
> specification allows a sender of a stream to set its priority, but I didn't
> immediately see how the receiver could request priority changes. [Flow
> control seems to be a slightly different thing].
>
>
The priority frame is for doing what you want. I agree the wording there is
funny, but either end can advertise their desired priority for the stream.
I believe the phrasing "sender-advised" just means it is the whole stream
priority judgment of the sender of the priority frame.



> (3) Modification of HTTP requests. The client may wish to change some
> fields of an HTTP request. Actually the only one I can think of right now
> is Range. For example of the client decides it does not need the whole of
> the originally requested range it would be more efficient to modify the
> Range than to wait until the required data is received and cancel the
> request.
>
>
that's not in there and without operational experience I personally
wouldn't favor it.. but feel free to make a proposal :)

hth