Re: Some HTTP 2.0 questions

Thanks for all the rapid responses.

- yes, it was the phrase "sender-advised" that confused me in the
definition of PRIORITY. It's not clear that the receiver of a stream can
request a change to its priority, but I understand from the responses below
that it's intended this is allowed
- modification of the request would indeed be something new at the HTTP
layer. But then this is HTTP2.0 ;-) The use-case I am thinking of is to
modify the Range, for example if the resource is somehow progressively
encoded and the client decides it only needs the lower layers. How would
this differ from canceling the old request and making a new one ? The
difference is admittedly minor unless the RTT is large: One could cancel
the old request, wait for any remaining data to arrive (one RTT) then send
the new request (another RTT). Or one could take a guess at where the old
request will finish and send both cancellation and new request at the same
time. But then depending on how good, or bad, your guess is you either have
duplicate data transfer or a gap. I accept the point some real world data
is necessary to motivate this use-case.

I have one follow-up question: IIUC, the notion of priority is 'soft' -
that is, the server can choose to return response data out of priority
order. How would you implement 'hard' priority, that is, where response
data must be returned in priority order, or, I guess, can only be
out-of-order if there is no data available to send from higher-priority
responses ?

...Mark



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

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