Re: Some HTTP 2.0 questions

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.
>

http://http2.github.io/http2-spec/#PRIORITY


>
>
>
>> (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
>