Experiences with HTTP/2 server push

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Experiences with HTTP/2 server push

Tom Bergan
Hi all,

Our team has been experimenting with H2 server push at Google for a few months. We found that it takes a surprising amount of careful reasoning to understand why your web page is or isn't seeing better performance with H2 push. We also encountered a lack of good documentation: How should one go about using H2 push? What are the best practices? We tried to distill our experiences into five "rules of thumb" that are described in this doc:

The doc is a little long, but the first two pages give a decent tl;dr. I suspect the ideas and conclusions will be "obvious" to many people on this mailing list, at least in hindsight. Hopefully other folks interested in H2 server push will find this useful. Let us know if you have any comments.

-Tom, Simon, and Michael
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Martin Thomson-3
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.

On 4 August 2016 at 10:21, Tom Bergan <[hidden email]> wrote:

> Hi all,
>
> Our team has been experimenting with H2 server push at Google for a few
> months. We found that it takes a surprising amount of careful reasoning to
> understand why your web page is or isn't seeing better performance with H2
> push. We also encountered a lack of good documentation: How should one go
> about using H2 push? What are the best practices? We tried to distill our
> experiences into five "rules of thumb" that are described in this doc:
> https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0
>
> The doc is a little long, but the first two pages give a decent tl;dr. I
> suspect the ideas and conclusions will be "obvious" to many people on this
> mailing list, at least in hindsight. Hopefully other folks interested in H2
> server push will find this useful. Let us know if you have any comments.
>
> -Tom, Simon, and Michael

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Tom Bergan
On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <[hidden email]> 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.

Let's say the server wants to prioritize a subset of streams differently than the priorities specified by the client, or differently from the default priorities. How should it actually implement this? The simplest implementation is to mutate the H2 priority tree directly. This makes the H2 priority tree the single prioritization data structure in the server. It's also attractive because H2 priorities can be communicated to lower layers like QUIC. We are aware of a few servers that update the priority tree like this, e.g., see Apache's h2_session_set_prio.

However, if the server does this, it has a problem: the H2 priority tree is a shared data structure. If it makes a change, its local copy of the data structure can be out-of-sync relative to the client's copy. A future PRIORITY frame from the client may have a different meaning than intended if the server has already changed its tree locally. The sentence you quoted describes the reactions of a naive server to this problem: Maybe I can keep the client's tree in sync by sending a PRIORITY frame? (Sorry for not making this more clear.) Of course, this doesn't actually solve the problem, since the server's PRIORITY frames could race with the client's. (Note that we're not aware of any servers that actually do this; we were just hoping to prevent any from trying.)

RFC 7540 talks about another kind of race: removing closed streams from the tree. The solution proposed by the RFC is to keep closed streams in the tree as long as possible. The RFC does not discuss this other kind of race -- reprioritizing streams on the server -- and this seems like something servers are very interested in doing. AFAIK, no one has really studied the impacts of this race nor provided guidance about how to avoid it. We don't have any great solutions, either, we just wanted to raise the problem to be sure that server implementors are aware of it.

On 4 August 2016 at 10:21, Tom Bergan <[hidden email]> wrote:
> Hi all,
>
> Our team has been experimenting with H2 server push at Google for a few
> months. We found that it takes a surprising amount of careful reasoning to
> understand why your web page is or isn't seeing better performance with H2
> push. We also encountered a lack of good documentation: How should one go
> about using H2 push? What are the best practices? We tried to distill our
> experiences into five "rules of thumb" that are described in this doc:
> https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0
>
> The doc is a little long, but the first two pages give a decent tl;dr. I
> suspect the ideas and conclusions will be "obvious" to many people on this
> mailing list, at least in hindsight. Hopefully other folks interested in H2
> server push will find this useful. Let us know if you have any comments.
>
> -Tom, Simon, and Michael

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Alcides Viamontes E-2
Let's say the server wants to prioritize a subset of streams differently than the priorities specified by the client, or differently from the default priorities. How should it actually implement this? The simplest implementation is to mutate the H2 priority tree directly. This makes the H2 priority tree the single prioritization data structure in the server. It's also attractive because H2 priorities can be communicated to lower layers like QUIC. We are aware of a few servers that update the priority tree like this, e.g., see Apache's h2_session_set_prio.

However, if the server does this, it has a problem: the H2 priority tree is a shared data structure. If it makes a change, its local copy of the data structure can be out-of-sync relative to the client's copy. A future PRIORITY frame from the client may have a different meaning than intended if the server has already changed its tree locally. The sentence you quoted describes the reactions of a naive server to this problem: Maybe I can keep the client's tree in sync by sending a PRIORITY frame? (Sorry for not making this more clear.) Of course, this doesn't actually solve the problem, since the server's PRIORITY frames could race with the client's. (Note that we're not aware of any servers that actually do this; we were just hoping to prevent any from trying.)

Hi. Great work over there. 

If browser and server are a bit far apart re-prioritization may arrive a bit too late to the server to be effective. Our solution for both  the race conditions and the RTT problem  is having our server learn the priorities and dependencies, build a delivery plan once and use it many times. In that sense, priorities and dependencies on the HTTP/2 spec as it is today is good enough for us. And the implementation complexity is about the same as implementing on-the-flight re-prioritization.
 

RFC 7540 talks about another kind of race: removing closed streams from the tree. The solution proposed by the RFC is to keep closed streams in the tree as long as possible. The RFC does not discuss this other kind of race -- reprioritizing streams on the server -- and this seems like something servers are very interested in doing. AFAIK, no one has really studied the impacts of this race nor provided guidance about how to avoid it. We don't have any great solutions, either, we just wanted to raise the problem to be sure that server implementors are aware of it.

This thing with closed streams takes a bit of getting used to. We have to be very careful to discard as much information as possible about closed streams as early as possible, but still keep some around for a little while to know which stream references from the browser are valid. Since we are not handling priority frames online, the amount of information we have to save is relatively small ("was this stream ever used?"), but if we were following the letter of the spec this would be a very worrying issue. 
 

> Our team has been experimenting with H2 server push at Google for a few
> months. We found that it takes a surprising amount of careful reasoning to
> understand why your web page is or isn't seeing better performance with H2
> push.

Oh, but it is a lot of fun :-)

In our experience as well the biggest performance killer of HTTP/2 Push is TCP slow start and the fact that push promises are bulky. Send many of them and an ACK round-trip will be needed. 

However, HTTP/2 Push *is* useful at other times as well. For example, if the server is using cache digests via cookies and it positively knows that the browser doesn't have a script referenced at the bottom of the page, like this:

       ...something
      <script src="/jquery.js?vh=3fhhwq"></script>, 

it can pause the HTML stream a little bit before "<script src", send a push promise for "/jquery.js?vh=3fhhwq", and resume sending the HTML document. Chances are that the TCP window is bigger by then.

Also notice a related scenario, which is a counter-pattern from the times of HTTP/1.1: instead of making a big HTML file including all  parts of a page, use (the closest thing to) HTML imports. If elements of a page that seldom change like navigation bar and visual footer are made imports, then they can be cached and traffic to the server can be reduced. Nobody does that because of latency. Using  HTTP/2 Push in the way described before, it becomes possible at no performance cost. 

Looked that way, HTTP/2 Push is a big deal for web components. And it is not far fetched, we are planning to release these features for ShimmerCat 1.7. The only thing we require from browser  is that they check if there is a push promise for a resource strictly -- but as late as possible -- before starting a fetch. 

The same can be done with hierarchies of scripts, although we will have to wait a bit for people to stop making big .js blobs.... 


--
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is a property of Zunzun AB)
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Amos Jeffries-2
On 6/08/2016 7:07 a.m., Alcides Viamontes E wrote:

>
> Looked that way, HTTP/2 Push is a big deal for web components. And it is
> not far fetched, we are planning to release these features for ShimmerCat
> 1.7. The only thing we require from browser  is that they check if there is
> a push promise for a resource strictly -- but as late as possible -- before
> starting a fetch.
>
> The same can be done with hierarchies of scripts, although we will have to
> wait a bit for people to stop making big .js blobs....
>

Any particular reason to wait?

Implementing it early allows demonstration that its faster not to use
blobs. Without that visible reason to change its unlikely that blobs
will disappear.

Amos


Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Martin Thomson-3
In reply to this post by Tom Bergan
On 6 August 2016 at 01:20, Tom Bergan <[hidden email]> wrote:

> On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Tom Bergan
Thanks all for the feedback.

On Fri, Aug 5, 2016 at 12:07 PM, Alcides Viamontes E <[hidden email]> wrote:
If browser and server are a bit far apart re-prioritization may arrive a bit too late to the server to be effective. Our solution for both  the race conditions and the RTT problem  is having our server learn the priorities and dependencies, build a delivery plan once and use it many times. In that sense, priorities and dependencies on the HTTP/2 spec as it is today is good enough for us. And the implementation complexity is about the same as implementing on-the-flight re-prioritization.

If you can come up with a complete delivery plan on the server, that is definitely ideal. There is some academic work that tries to do this (see Klotski: https://www.usenix.org/node/189011). I also liked your "Coordinated Image Loading" article as an example of why server-defined priorities can be a good idea. I am curious though -- how do you deal with cases where the page is heavily dynamic and some of the important content may be fetched by XHRs? Do you expect that the full dependency information is available a priori, before the main response is served to the client?
 
> Our team has been experimenting with H2 server push at Google for a few
> months. We found that it takes a surprising amount of careful reasoning to
> understand why your web page is or isn't seeing better performance with H2
> push.

Oh, but it is a lot of fun :-)

It is for us too :-), but I imagine many devs would find it frustrating. Hence our attempt to try to distill our experiences into a "best practices" doc.
 
In our experience as well the biggest performance killer of HTTP/2 Push is TCP slow start and the fact that push promises are bulky. Send many of them and an ACK round-trip will be needed. 

Interesting point about needing ACK round-trips just to send the push promises. We hadn't run across that problem specifically. Is this because you're sending many push promises? Is there some reason why hpack cannot compress a sequence of push promises?

If you've released any data about HTTP/2 Push performance in ShimmerCat, I'd be interested to read it. I did notice one article on your site, although that only dealt with one page with a fixed network connection:

On Sun, Aug 7, 2016 at 7:02 PM, Martin Thomson <[hidden email]> wrote:
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'm not sure what I misunderstand? It sounds like we're saying the same thing: the server should not mutate the priority tree if it wants to continue using priority information from the client. (The counter-point is Alcides' example, where the server uses its own delivery plan and ignores the client's PRIORITY frames entirely.)

Note that no client I'm aware of will do anything with the server's
PRIORITY frames, let alone adjust its own priority tree.

To be clear:

* As I mentioned above, I'm not aware of any server that tries to send PRIORITY frames to the client. That discussion was intended to dissuade a naive server from attempting to do so. AFAIK, servers that do mutate the priority tree just mutate the server's in-memory representation of the tree, e.g., I believe this is what Apache does with h2_session_set_prio, which is applied to pushed streams (more info here).

* Apache is technically not doing anything illegal. Servers are free to do anything they want with priority information. (From Section 5.3: "priority for a stream is input to a prioritization process. It does not guarantee any particular processing or transmission order for the stream relative to any other stream ... priority is therefore only a suggestion".) The problem comes when servers want to mix their own priorities (e.g., for pushes) with the client's priorities. It is tempting to do this by mutating a single data structure. RFC 7540 doesn't discuss this temptation at all, which is why we discussed it in our document.
Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Alcides Viamontes E-2

If you can come up with a complete delivery plan on the server, that is definitely ideal. There is some academic work that tries to do this (see Klotski: https://www.usenix.org/node/189011). I also liked your "Coordinated Image Loading" article as an example of why server-defined priorities can be a good idea. I am curious though -- how do you deal with cases where the page is heavily dynamic and some of the important content may be fetched by XHRs? Do you expect that the full dependency information is available a priori, before the main response is served to the client?

Thanks for the link! I will take a closer look. 

About dynamic content, so far we have focused on xhr content which is fetched on initial page load. From version 1.0 up to 1.4 we have included a learning mode that introduces small, artificial random pauses between DATA frames of an HTTP/2 stream. We also make the  frames purposely small and variable, say arond 512 bytes in length. Then we record the time when each frame is delivered (as well as our server can know from the blanket of abstractions that the OS provides). During initial page load multiple streams are being downloaded in parallel, and the pauses help to improve (up to a point, before the law of large numbers kicks in) overall randomness in the process.  Therefore, on repeated loads of the same page, frames from different streams which are almost always delivered very close in time point out to some correlation between their streams. We sort the correlations on the order of possible causality, and we postulate that there is a dependency between the two streams. This works well even for xhr content, where the browser doesn't provide explicit dependency information.

In simpler words, we use statistics to try to infer dependencies from the browser's behavior. The only downside of our technique is that it uses too much computing power to be able to run under 10 seconds on a developer's laptop, because each page of the site which is significantly different to the others needs to be fetched several times by a typical user agent, e.g., a browser. It would work great as a cloud service though. And it is also good enough to run as part of CI workflows. 

 
 
> Our team has been experimenting with H2 server push at Google for a few
> months. We found that it takes a surprising amount of careful reasoning to
> understand why your web page is or isn't seeing better performance with H2
> push.

Oh, but it is a lot of fun :-)

It is for us too :-), but I imagine many devs would find it frustrating. Hence our attempt to try to distill our experiences into a "best practices" doc.
 
In our experience as well the biggest performance killer of HTTP/2 Push is TCP slow start and the fact that push promises are bulky. Send many of them and an ACK round-trip will be needed. 

Interesting point about needing ACK round-trips just to send the push promises. We hadn't run across that problem specifically. Is this because you're sending many push promises? Is there some reason why hpack cannot compress a sequence of push promises?

 
Yes, in our early prototypes we just wanted to see how far the technique would take us, so we grabbed a bloated HTML template and tried to push all of it in the order our algorithms were spitting out ;-) . 
 
If you've released any data about HTTP/2 Push performance in ShimmerCat, I'd be interested to read it. I did notice one article on your site, although that only dealt with one page with a fixed network connection:


What would you consider an interesting, standard measure for this case? We are mainly interested on reducing the impact of latency on page load time. So we tend to measure how the page load time decreases  for a client  with latency around 120 ms. That's easy to standardize, but the other variable is the website itself and that one is harder to standardize. In our consultancy projects we tend to set a 30 to 50% improvement in load time and time-to-start-reading over baseline as an achievable target goal, but each project is quite unique :-( . 

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Kazuho Oku
In reply to this post by Martin Thomson-3
2016-08-08 11:02 GMT+09:00 Martin Thomson <[hidden email]>:

> On 6 August 2016 at 01:20, Tom Bergan <[hidden email]> wrote:
>> On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Martin Thomson-3
On 15 August 2016 at 07:15, Kazuho Oku <[hidden email]> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Kazuho Oku
2016-08-15 10:14 GMT+09:00 Martin Thomson <[hidden email]>:
> On 15 August 2016 at 07:15, Kazuho Oku <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Experiences with HTTP/2 server push

Matthew Kerwin
In reply to this post by Martin Thomson-3


On 15 August 2016 at 11:14, Martin Thomson <[hidden email]> wrote:
On 15 August 2016 at 07:15, Kazuho Oku <[hidden email]> 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.


​I think the key here is "part of"... unlike HEADERS, PUSH_PROMISE doesn't have priority fields. If it did, this would be true. I'm still not sure what it would mean, though.

Cheers
--
  Matthew Kerwin
  http://matthew.kerwin.net.au/