New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WebLink] Do not push known assets to the client #28698

Open
digilist opened this Issue Oct 3, 2018 · 0 comments

Comments

Projects
None yet
2 participants
@digilist
Contributor

digilist commented Oct 3, 2018

The introduction of server push with the WebLinkExtension and the preload() function in Twig is a great way to improve web performance.

With the current implementation, the Link header is always set and does not consider that the client already knows a specific asset. So in the worst case, the server is pushing the same asset again and again, even though it is already known to the client. So this leads to unnecessary traffic and loading time, especially on small connections.

Actually, the browser has a way to abort server pushes and "say" that it already knows the asset (https://stackoverflow.com/a/29354100/1044527). However, when the browser is ready to abort a transfer, parts of the asset (or the whole asset) might already be transferred. (see https://www.fastly.com/blog/optimizing-http2-server-push-fastly under "Looking ahead")

In the future there might come Cache Digests, that allows clients to inform the server of their cache's content. However, as this proposal is not ready yet, I think there is a need for a temporary solution.

The H2O webserver solves this problem by setting a cookie with a fingerprint of all pushed assets (based on a Bloom filter) which is called CASPer (cache-aware server-push).

When enabled, H2O maintains a fingerprint of the web browser cache, and cancels server-push suggested by the handlers if the client is known to be in possession of the content. The fingerprint is stored in a cookie named h2o_casper using Golomb-compressed sets (a compressed encoding of Bloom filter).

I think a similar solution would be great for Symfony. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment