Re: Sending priority from a server

On 12/07/2014 4:07 p.m., David Krauss wrote:
> 
> On 2014–07–12, at 12:01 PM, Roberto Peon <grmocg@gmail.com> wrote:
> 
>> I used to think sending the priority from the server was a decent
>> idea, but then I though about exactly what Martin is worried
>> about: If the server informs the client about how it is
>> prioritizing, and the client disagrees, then it attempts to change
>> it. .. and if the server then advertises the same thing... .. rinse
>> repeat.
>> 
>> You can get into nasty situations.
>> 
>> It is more robust to simply have the client state the priority if
>> it cares.
> 
> How does the client know whether it cares to reprioritize if it
> doesn’t know the current priority?
> 
> As I mentioned, setting the initial priority of every push to
> default=16 is both nonviable and meaningless.
> 
> What’s left is to attempt retrospective detection based on relative
> stream rates, which is slow, difficult, and error-prone.
> 
> A feedback loop is easily averted by not sending more than one
> PRIORITY per stream (!). We’re not talking about PRIORITY frames from
> the server here, only a prioritization field in PUSH_PROMISE.
> 

Lets converse then:

client: HEADERS (s=1, p=999)
  "I want this. top-priority!"

server: PUSH (s1 + s=2, p=4)
   "s=1 comes with extras. I will send in background, real SLOW"

client: PRIORITY (s=2, p=999)
  "I want those top-priority as well!"


Seems reasonable information exchange. Still no obligation on the server
to actually use the client hints.

Amos

Received on Saturday, 12 July 2014 08:51:55 UTC