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 09:05:44 -0800
Message-ID: <CAP+FsNc6OXbANDxXVUVMPcNE+N=cMs4NzZduuXYnna6Qz418LQ@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Look for the thread entitled:

Restarting the discussion on HTTP/2 stream priorities

(started on Oct 28)

for further details about how we'd like to see priority changed.

On Wed, Dec 4, 2013 at 8:49 AM, Roberto Peon <grmocg@gmail.com> wrote:

> 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
Received on Wednesday, 4 December 2013 17:06:16 UTC

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