Re: Experiences with HTTP/2 server push

[Kazuho Oku <[e-mail]>]

2016-08-15 10:14 GMT+09:00 Martin Thomson <[e-mail]>:
> On 15 August 2016 at 07:15, Kazuho Oku <[e-mail]> wrote:
>> 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.
>
> I don't think that makes sense.  If the client processes the
> PUSH_PROMISE and immediately reprioritizes the push, then the PRIORITY
> frame that appears afterwards will be exactly as meaningless or
> destructive as anything else.

Sorry, I agree with you on this point. My misunderstanding was that it
was possible to embed priority information within PUSH_PROMISE frame
like the way that can be done with a HEADER frame.

>> 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.
>
> This is good advice.
>
>>>> 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.
>
> I couldn't parse this.  Do you mean that you ignore the client's
> express priorities, or work within the client's priorities?

Generally speaking, a server should respect the priority tree
constructed by the client if it considers the client's knowledge of
how the responses should be ordered superior to the knowledge of the
server. OTOH, if a server considers itself to have better knowledge on
how to prioritize the streams, then it should ignore client-driven
prioritization.

Since the client cannot accurately prioritize a pushed stream until
client observes how the resource is used, server-driven prioritization
of pushed streams is necessary until client updates the priority of a
pushed stream.

So our approach is to create a separate tiny pool of streams _above_
the HTTP/2 prioritization tree, and initially register the pushed
streams with certain media types (e.g. CSS, JavaScript) to the tiny
pool. The server does not send PRIORITY frames for the pushed streams.

This means that until the client sends a PRIORITY frame to update the
precedence of a pushed stream, pushed CSS and JS will be sent before
any other responses. Once the server receives a PRIORITY frame, then
the pushed streams will be prioritized as specified by the client.

-- 
Kazuho Oku