server-push - specified - request header cache control
¿El navegador cancela la inserción del servidor cuando un recurso está en caché? (2)
En HTTP / 2, el servidor envía al cliente una solicitud para el recurso con un marco PUSH_PROMISE.
Al pasar del servidor al cliente, esto no es una respuesta, sino una solicitud, la solicitud que el cliente haría para obtener ese recurso.
Cuando el cliente recibe el PUSH_PROMISE, puede ver el URI y averiguar el estado del caché de este recurso. Los navegadores suelen utilizar diferentes cachés para los recursos recibidos normalmente y los recursos empujados. Si el caché sigue siendo válido, el cliente puede cancelar el flujo enviado enviando un marco RST_STREAM al servidor para ese flujo.
Mientras tanto, el servidor comienza lo que se necesita para impulsar el recurso. Esto generará un marco de respuesta de HEADERS que contendrá los encabezados de respuesta típicos, como etag. Cuando el cliente recibe el marco de respuesta HEADERS, tiene una oportunidad más para cancelar el flujo, aunque, por supuesto, los marcos de DATOS pueden ser en vuelo, posiblemente todos.
El ahorro de ancho de banda puede ser interesante, pero normalmente no es un problema desperdiciar un poco de ancho de banda; lo que importa más desde el punto de vista de la experiencia del usuario es la latencia, y el mecanismo de empuje lo reduce en una cantidad considerable.
No creo que el mecanismo de inserción comprometa la optimización de la memoria caché del cliente; si este hubiera sido el caso, los proveedores de navegadores habrían luchado contra esta característica, mientras que la mayoría de ellos (si no todos) lo implementan con muy buenos resultados en la experiencia del usuario y la latencia disminuida.
Claro que el mecanismo podría mejorarse, por ejemplo, haciendo que los clientes y los servidores se pongan de acuerdo sobre algún encabezado que proporcione más información sobre el recurso que se está enviando, pero hasta ahora funciona bastante bien.
[Descargo de responsabilidad: soy un comentarista de Jetty] Habiendo sido el primero en implementar SPDY y HTTP / 2 Push para el ecosistema de Java (hace casi 3 años ), el Proyecto Jetty ciertamente está interesado en más discusiones e ideas sobre HTTP / 2 Push.
La especificación HTTP / 2 indica que cualquier recurso identificado en un marco PUSH_PROMISE no se enviará si el cliente lo cancela.
Cuando un navegador detecta un recurso que ya se encuentra en el caché, debe cancelar la inserción de este recurso. Sin embargo, no veo cómo el navegador puede detectarlo. ¿Los marcos proporcionan información adicional como etag o última modificación para permitir que el navegador detecte si se debe desalojar alguna entrada de caché o si se puede cancelar la inserción?
Si es posible, se podría guardar algo de ancho de banda. Sin embargo, parece que el empuje del servidor compromete la optimización de la caché del cliente.
Respuesta simple y breve: sí, el navegador cancelará la inserción del servidor si tiene esta URL en el caché.