Re: Some HTTP 2.0 questions

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