Re: Nit: Server-sent priority

The only use case I understand, in an HTTP context, for server sent
priority is on a pushed stream. And in that case the priorities are
distinctly not independent between the client and server initiated streams
(though they all apply to the response body sender).

In that case the client has to know the priority the sender is using on the
new stream (and potentially change it) so that future streams initiated by
the client can have their priorities set in a relative weigh.

An example: the client requests index.html at priority 3, the server pushes
img1 and css1. All three resources are still transferring and the client
now wants to pull img2 and img3 at the same priority as img1 (which is
still flowing) but a lower priority than css1. What priorities does it use
in its requests? It can't get that right without knowing what priority the
server has assigned to those pushes.

Is there another use case here?



On Wed, Jun 19, 2013 at 4:06 AM, Mike Belshe <mike@belshe.com> wrote:

> Accidentally sent this only to Martin.
>
> Looks like James and I had the same answer.
>
> ---------- Forwarded message ----------
> From: Mike Belshe <mike@belshe.com>
> Date: Tue, Jun 18, 2013 at 5:09 PM
> Subject: Re: Nit: Server-sent priority
> To: Martin Thomson <martin.thomson@gmail.com>
>
>
>
>
>
> On Tue, Jun 18, 2013 at 3:42 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> We discussed the possibility that a server could send PRIORITY (either
>> in its own frame or attached to HEADERS).  The idea was that the
>> server could advise a client about the priority that it is applying,
>> which might be different to the priority that a client requested.
>>
>
> I am not sure how the client would use this information.
>
> The intent of priority was to indicate what order you'd like the other
> side to process the streams.  If its a full-duplex stream (not likely
> HTTP), the server and client can each assign a different priority to the
> other side.
>
> They're just independent.
>
>
>>
>> This adds a challenge for clients: does the client now provide updated
>> priorities that are relative to the priorities that it sent
>> previously, or relative to the priority that the server has indicated?
>>
>
> Indeed confusing - more reason not to do this :-)
>
>
>>
>> e.g., client sends three requests, priority 7, 10 and 15.  Server
>> responds and indicates priorities of 3, 5 and 7.  If the client wants
>> to issue a new request that is higher priority than the lowest
>> priority existing request, does it indicate a priority of between 10
>> and 15?  Or does it indicate a priority of 6?
>>
>
> 10< pri <15
>
>
>> This editor wants to know.  I think that the easiest approach would be
>> to stipulate that the priorities spaces are independent and that
>> client priorities are only relative to client priorities.
>> Unfortunately, that means that I need to include the example above as
>> well.
>>
>
>
>
>>
>> I don't want to prohibit servers from sending priority, because I
>> believe that it could be useful for a client to understand how
>> priority is being applied.
>>
>
> I'm not sure how the client would use that information - dynamically
> adjust?  This seems like a non-use case.
>
>
> Mike
>
>
>
>
>
>