I was wondering if others experience this too: New(er) versions of Chrome seem to have difficulties with our pushed resources. The behaviour is erratic, and Chrome sometimes downloads some or all of the pushed resources a second time. Example: WebPageTest - Running web page performance and optimization tests...
I have never seen this in the past and I do not see this behaviour with Firefox.
I don’t know if it will show why Chrome chose not to adopt the pushed stream but enabling netlog capture might provide more details (in the chrome tab) or at least provide what the Chrome net team would need for a bug on http://crbug.com
I know it can be relatively sensitive about the pushed headers matching the actual request headers but aside from cookies and the accept header they appear to match up.
One issue may be all of the link rel=preload http headers don’t have an “as” type and that may be triggering both the preloader to fetch the resources as well as them to be pushed (and possibly a difference from when the actual resources are fetched). It could be that the pushed resources are being adopted by the preload requests but are being thrown away because the type doesn’t match the actual type requested later.
If you add proper “as” attributes to the preload requests it may fix the issue.
Thanks for the answers - I will check with the developers of the h2o webserver on how I could add the “as” to the preload header. Until now, none of the browsers (including Chrome) had an issue with this. And what really puzzles me: That Chrome does not seem to react predictably.
The issue seems to have gone away with the use of the relative “as” attribute in the preload link!!! I filed an issue with the h2o documentation, so that the configuration examples are updated accordingly.
Many thanks for your help!