W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2016

Re: Experiences with HTTP/2 server push

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 8 Aug 2016 12:02:14 +1000
Message-ID: <CABkgnnWCm4gJ7fg3b8Ud=oBq5xYosoy3q=F3Tn_ChsXE4wHXaQ@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 6 August 2016 at 01:20, Tom Bergan <tombergan@chromium.org> wrote:
> On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>> I didn't read through this in detail, but there is a fairly big error
>> here when it comes to the description of using priorities.  You say:
>> > One way to implement this is for the server to update its HTTP/2
>> > priority tree, **then send PRIORITY frames to the client that make A the
>> > exclusive parent of C** and C the exclusive parent of D. This is an
>> > attractive implementation because the server can continue using the HTTP/2
>> > priority tree to order requests C, D, and B.
>> The server can't send PRIORITY frames in this way.  Or at least, that
>> won't have the effect you think it does.
>> The server can (and should) just send as it sees fit, using as input
>> its own knowledge and the priority that the client has provided.  If
>> the server sends PRIORITY, that is to affect client processing (hint:
>> that's not going to happen here). Given that the space that you are
>> examining is a problem for server-to-client transmission only, the
>> server expressing priority is pointless.
> Yes, we agree with you. The point of that section is that the server should
> *not* send PRIORITY frames like that. Here's the next paragraph:
>> However, this is fundamentally racey: if both ends (client and server)
>> update the priority tree concurrently, it can easily become out-of-sync. For
>> this reason, we advocate not mutating the priority tree on the server.

I think that you still misunderstand.  The priority tree is the
client's data.  The server cannot mutate it because it doesn't own it.
As you say, if the server makes changes, the state is ruined.  Note
that no client I'm aware of will do anything with the server's
PRIORITY frames, let alone adjust its own priority tree.

> We are aware of a few servers that update the priority tree like
> this, e.g., see Apache's h2_session_set_prio.

Stefan, is this right?  See above.
Received on Monday, 8 August 2016 20:55:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 8 August 2016 20:55:56 UTC