W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Some HTTP 2.0 questions

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 4 Dec 2013 08:49:42 -0800
Message-ID: <CAP+FsNe+OdQj7Yg4_-sAf82tCC9aOhEHZnC34syNtkwR1eSQGA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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?


Thanks in advance for any pointers on these. If they are new features
> requiring more detailed use-cases I can provide those.
> ...Mark
Received on Wednesday, 4 December 2013 16:50:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC