Dans HTTP/2, le serveur envoie au client une requête pour la ressource avec une trame PUSH_PROMISE. Tout en passant du serveur au client, ce n'est pas une réponse, mais une requête, la requête que le client ferait pour récupérer cette ressource. Lorsque le client reçoit le PUSH_PROMISE, il peut regarder l'URI et déterminer l'état de cache de cette ressource.
Les navigateurs utilisent généralement différents caches pour les ressources normalement reçues et les ressources poussées. Si le cache est toujours valide, le client peut annuler le flux enfoncé en envoyant une trame RST_STREAM au serveur pour ce flux.
Pendant ce temps, le serveur démarre ce qu'il faut pour pousser la ressource. Cela générera une trame de réponse HEADERS qui contiendra les en-têtes de réponse typiques tels que etag. Lorsque le client reçoit la trame de réponse HEADERS, il a une chance de plus d'annuler le flux, bien que - bien sûr - les trames DATA puissent être en clair, éventuellement toutes.
L'économie de bande passante peut être intéressante, mais il n'est généralement pas un problème de gaspiller une petite bande passante; ce qui importe le plus du point de vue de l'expérience de l'utilisateur est la latence, et le mécanisme de poussée réduit cela d'une quantité considérable.
Je ne pense pas que le mécanisme de poussée compromet l'optimisation du cache client; Si cela avait été le cas, les vendeurs de navigateurs se seraient battus contre cette fonctionnalité, tandis que la plupart d'entre eux (sinon tous) l'implémenteraient avec de très bons résultats dans l'expérience utilisateur et une latence réduite. Bien sûr, le mécanisme pourrait être amélioré, par exemple en faisant en sorte que les clients et les serveurs se mettent d'accord sur un en-tête qui donnera plus d'informations sur la ressource qui est poussée, mais fonctionne assez bien jusqu'à présent.
[Disclaimer: Je suis un committers de la jetée] Après avoir été le premier à mettre en œuvre SPDY et HTTP/2 Poussez pour l'écosystème Java (almost 3 years ago), le Jetty Project est certainement intéressé par more discussions and ideas autour HTTP/2 Push.
Je suis curieux de savoir quel mécanicien le client utilise pour savoir s'il peut annuler le push. Est-ce qu'un etag ou dernier modifié ou quelque chose envoyé avec la promesse push? Cette page Chromum sur SPDY semble indiquer qu'un PUSH serait redondant (ignore le cache) et un HINT demanderait au navigateur de récupérer l'objet, après avoir vérifié son cache: https://www.chromium.org/spdy/link-headers -and-server-hint Est-ce que ce mécanisme a changé entre SPDY et HTTP2? – CodingWithSpike
En plus de mon commentaire ci-dessus, il y a un fil de discussion Chrome ici https://groups.google.com/a/chromium.org/forum/#!msg/net-dev/yfkW4mkWIPU/CEVL86nFJgAJ (plus spécifique à SPDY) qui indique qu'il n'y a pas de support pour la mise en cache push du serveur. Les fichiers poussés par le serveur à partir d'un serveur HTTP2 n'apparaissent pas dans 'chrome: // cache' (le fichier initialement demandé apparaît dans le cache, mais les fichiers supplémentaires ne le sont pas). Je pense que la spécification HTTP2 pourrait laisser un navigateur recevoir un etag dans le PUSH_PROMISE et annuler le push, mais il semblerait que Chrome, au moins, ne soit pas implémenté de cette façon. – CodingWithSpike