Re: Experiences with HTTP/2 server push

[Kazuho Oku <[e-mail]>]

2016-08-08 11:02 GMT+09:00 Martin Thomson <[e-mail]>:
> On 6 August 2016 at 01:20, Tom Bergan <[e-mail]> wrote:
>> On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <[e-mail]>
>> 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.

I agree with Martin that a server should never send a PRIORITY frame.

OTOH let me note that a server can also send priority information as
part of a PUSH_PROMISE frame. This way, the priority tree does not get
ruined.

Ideally, I think clients should send PRIORITY frames when it finds out
how the content of a pushed stream is used, so that a server (that
consider clients to have better understanding of how the resources
should be prioritized) can respect the updated tree to prioritize the
pushed streams.

>> 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.

In case of H2O, we prioritize pushes of certain media types, but that
is done out of the HTTP/2 prioritization tree. I think that is the way
to go.

-- 
Kazuho Oku