Re: Some HTTP 2.0 questions

On Wed, Dec 4, 2013 at 8: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 ?
>
> A stream is a single request for HTTP/2.
Cancelling the stream cancels a request.


> (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].
>
>
This is an open issue and is being worked on.


> (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.
>
>
I do't think we've heard about this as a compelling usecase for anyone yet.
Why would this be significantly better than cancelling the previous request
and sending another?

-=R

Thanks in advance for any pointers on these. If they are new features
> requiring more detailed use-cases I can provide those.
> ...Mark
>