RE: #539: Priority from server to client

Hervé is correct that the spec currently under-defines what it means when a PRIORITY frame goes from server to client.  However, there are a couple different options for what it might mean:
  1) Server declares the priority it has placed on a stream.
        + What if it's racing with a client-sent PRIORITY frame?
  2) Server informing the client how the client ought to allocate resources
        + Really only makes sense if the client has multiple large PUT/POSTs going on
  3) Server can't send these.

In NYC, we closed a related issue of having the server send its initial priority in the PUSH_PROMISE.  If we picked the first, that would be a natural corollary to the optional presence of PRIORITY in the HEADERS frame.

I do think we should define one, just so there aren't different semantics on both sides of the connection.  I agree that the first makes me itch slightly.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Tuesday, July 1, 2014 12:09 AM
To: HTTP Working Group
Subject: #539: Priority from server to client

<https://github.com/http2/http2-spec/issues/539>

I thought we'd discussed this a bit in NYC, but don't see anything in the minutes. 

How do people feel about this? Herve has made a proposal in a pull request:
  <https://github.com/http2/http2-spec/pull/526/files>

Personally, my .02 - I get nervous when a protocol element has different semantics depending on what direction it's travelling; e.g., Cache-Control turned out to be very confusing. It feels like that's going on here too; in one direction, it's a priority request, whereas in the other it seems like a declaration...

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 1 July 2014 14:27:43 UTC