- From: David Krauss <potswa@gmail.com>
- Date: Sat, 12 Jul 2014 12:07:06 +0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Saturday, 12 July 2014 04:07:47 UTC