En caso de HTTP 304 Not Modified-respuestas contienen las cabeceras de control de caché?

StackOverflow https://stackoverflow.com/questions/1587667

  •  22-09-2019
  •  | 
  •  

Pregunta

He tratado de entender esto, y buscado SO para preguntas similares, pero todavía no tienen una comprensión del 100% de lo que se supone que el trabajo.

recibo esta respuesta a una solicitud de un recurso de imagen:

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:04:04 GMT
    Expires Mon, 19 Oct 2009 09:06:05 GMT
    Cache-Control   public, max-age=120
    Etag    image_a70703fb393a60b6da346c112715a0abd54a3236
    Content-Disposition inline;filename="binary-216-420"
    Content-Type    image/jpg;charset=UTF-8
    Content-Length  4719

El comportamiento deseado es que el cliente debe almacenar en caché este durante 120 segundos, y luego solicitarlo al servidor de nuevo. Dentro de los 120 segundos, sin solicitud se envía al servidor.

A continuación, después de 120 segundos, se envía una solicitud y se recibe una respuesta 304:

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:06:13 GMT

Request Headers
    Host    localhost:8080
    User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
    Accept  image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language en-us,no;q=0.8,sq;q=0.7,en;q=0.5,sv;q=0.3,nn;q=0.2
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  300
    Connection  keep-alive
    Referer http://localhost:8080/cms/site/0/en/home
    Cookie  JSESSIONID=768ABBE1A3BFABE3B535900233330650; versionsCssDisplayState=block; iceInfo=iceOn:false,activePortletKey:,icePagePanelX:1722,icePagePanelY:3
    If-None-Match   image_a70703fb393a60b6da346c112715a0abd54a3236

Hasta ahora, todo bien. Pero entonces, en la siguiente petición (whithin 120 segundos), habría pensado que el recurso debe almacenar en caché durante 120 segundos nuevas. Lo que veo en el navegador (Firefox), por otro lado, es que a partir de ahora siempre solicitar el recurso y recibe el 304-respuesta.

¿Se supone que unir las cabeceras de control de caché en el 304-respuesta? Por lo que puedo leer en la especificación, parece que los ajustes de control de caché debe ser omitido, y que el caché debe almacenar en caché durante 120 segundos nuevas de forma automática?

¿Fue útil?

Solución

En teoría no debería tener que enviar Cache-Control para un 304 - el destinatario sólo debe seguir utilizando las directivas de caché que recibió de la original 200. Sin embargo, como usted ha encontrado, en la práctica si no sigan enviando Cache-control, navegadores ignorar las directivas de caché que ha enviado originalmente, y vuelven a sus propios heurística por defecto.

Por lo tanto, en la práctica, que debe incluir el mismo Cache-Control con un 304 que lo haría con un 200. Los únicos mandatos de especificaciones que lo envíe a un 304 si es diferente a lo que ya haya enviado (ver 10.3.5 304 sin modificar ) - pero ciertamente no lo hace prohibir que se vuelva a repetir cuando es el mismo.

Y para responder específicamente a los puntos erróneos de cabeza de la otra respuesta (Estructura de):

  1. hacer quieren cachés intermedias para almacenar en caché la respuesta (es decir, actualizar su entrada de caché para el recurso). Ellos responderán adecuadamente a las peticiones de los clientes con un 200 o un 304, dependiendo de si el cliente incluye una cabecera condicional como Si-Modified-Since.

  2. El segundo TTL-120 ser refrescada por el 304 (por lo que el mismo cliente no debe hacer otra solicitud para el mismo recurso para al menos otros 120 segundos). Y los clientes, siempre y cuando todavía tienes el contenido almacenado en caché, continuar para hacer peticiones condicionales para el recurso, que se puede seguir respondiendo a un 304.

Otros consejos

RFC7232 RFC2616 actualizaciones decir:

  

El servidor de generar una respuesta 304 DEBE generar cualquiera de las      siguientes campos de cabecera que habría sido enviado en un 200 (OK)      respuesta a la misma petición: Cache-Control, Content-Location, fecha,      ETag, Expira, y varían.

Si entiendo correctamente, entonces el navegador es, de hecho, el almacenamiento en caché durante 120 segundos y el servidor está respondiendo a 304 Not Modified posterior If-Modified-Since solicitudes. Esta petición "IMS" se produce cuando el usuario final accede a la misma URL. En ese momento el navegador puede enviar una solicitud If-Modified-Since. El navegador quiere saber si se está mostrando contenido obsoleto. Esto parece normal.

Al recibir esta petición el servidor debe responder OK 200, 304 sin modificar (o una 4XX, si es necesario).

No creo que usted debe configurar su servidor para enviar una cabecera Cache-Control con la respuesta 304 por dos razones:
1. Usted no quieren cualquier caché como intermediarios a los que caché 304 respuesta (hay una posibilidad de que pudiera)
2. El 120 segundos TTL no se actualizará por la respuesta 304. El navegador retendrá el objeto durante 120 segundos a partir de la respuesta 200 OK. Después de 120 segundos, el navegador debe enviar una petición GET, no un If-Modified-Since, por lo que el servidor responderá con los bytes del archivo y no sólo una respuesta 304.

Tenga en cuenta que el navegador no solicitará el archivo de nuevo automáticamente después de 120 segundos a menos que el usuario final lo pidan expresamente a través de una carga de la página o introduciendo directamente la dirección URL en su barra de direcciones (o menos que tenga una aplicación personalizada que los controles que la funcionalidad de alguna manera).

Edited el primer párrafo para leer un poco mejor (es de esperar)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top