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

Re: Some HTTP 2.0 questions

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 4 Dec 2013 08:56:51 -0800
Message-ID: <CAA4WUYjEm055L907Nr_nTjH3jAdN0w5Uc0xRuJN0GXmCdE9VVw@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Mark Watson <watsonm@netflix.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Dec 4, 2013 at 8:52 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

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

Just to be clear, this is a change of HTTP semantics, right? While HTTP/2
the framing layer supports sending multiple HEADERS frames, which could
update those headers, this is not anything the web platform nor the HTTP
semantic layer currently support. HTTP/2 currently tries to avoid such
semantic changes and primarily focuses on the application transport. A
different semantic layer on top of the HTTP/2 framing layer definitely
could do this though.

> hth
Received on Wednesday, 4 December 2013 16:57:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC