para - http/1.1 200 ok

¿Cuál es la diferencia entre el código de estado HTTP 200(caché) frente al código de estado 304?

Question

Estoy usando el complemento de Google "Page Speed" para que Firefox acceda a mi sitio web.

Algunos de los componentes en mi página se indican como estado HTTP:

200 200 (caché) 304

Por la "velocidad de página" de Google.

Lo que me confunde es la diferencia entre 200 (caché) y 304.

He refrescado la página varias veces (pero no he borrado mi caché) y siempre parece que mi favicon.ico y algunas imágenes tienen el estado = 200 (caché), mientras que algunas otras imágenes tienen el estado http 304.

No entiendo por qué la diferencia.

ACTUALIZAR :

Utilizando Google "Page Speed", recibo un "200 (caché)" para http://example.com/favicon.ico así como http://cdn.example.com/js/ga.js

Pero, recibo un estado http "304" para http://cdn.example.com/js/combined.min.js

No entiendo por qué tengo dos archivos JavaScript ubicados en el mismo directorio / js /, uno devuelve un estado http 304 y el otro devuelve un código de estado 200 (caché).

Answer 1

200 (caché) significa que Firefox simplemente está utilizando la versión localmente en caché. Este es el más rápido porque no se realiza ninguna solicitud al servidor web.

304 significa que Firefox está enviando una solicitud condicional "If-Modified-Since" al servidor web. Si el archivo no se ha actualizado desde la fecha enviada por el navegador, el servidor web devuelve una respuesta 304 que básicamente le dice a Firefox que use su versión en caché. No es tan rápido como 200 (caché) porque la solicitud todavía se envía al servidor web, pero el servidor no tiene que enviar el contenido del archivo.

A su última pregunta, no sé por qué los dos archivos JavaScript en el mismo directorio están devolviendo resultados diferentes.

Answer 2

304 no está modificado. Obtengo este código mucho en mis archivos de medios como css y js.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5

Answer 3

Esto me causó mucho tiempo también. Lo primero que verificaría es que no está recargando la página haciendo clic en el botón Actualizar, que siempre emitirá una solicitud condicional de recursos y devolverá 304 para muchos de los elementos de la página. En lugar de eso, vaya a la barra de direcciones, seleccione la página y presione enter como si acabara de escribir en la misma URL, que le proporcionará un mejor indicador de lo que se almacena correctamente. Este artículo hace un excelente trabajo al explicar la diferencia entre las solicitudes condicionales e incondicionales y cómo les afecta el botón de actualización: http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about-conditional-http-requests-and-the-refresh-button.aspx

Answer 4

HTTP 304 no está "modificado". Su servidor web básicamente le dice al navegador "este archivo no ha cambiado desde la última vez que lo solicitó". Mientras que un HTTP 200 le dice al navegador "aquí hay una respuesta exitosa", que debe devolverse cuando es la primera vez que su navegador accede al archivo o la primera vez que se accede a una copia modificada.

Para obtener más información sobre los códigos de estado, consulte http://en.wikipedia.org/wiki/List_of_HTTP_status_codes .

Answer 5

Para su última pregunta, ¿por qué? Trataré de explicar con lo que sé

Una breve explicación de esos tres códigos de estado en términos simples.

• 200 - éxito (solicitudes del navegador y obtener archivo del servidor)

Si el almacenamiento en caché está habilitado en el servidor

• 200 (desde la memoria caché): archivo encontrado en el navegador, por lo que el navegador no está solicitando el servidor
• 304 - el navegador solicita un archivo pero el servidor lo rechaza

Para algunos archivos, el navegador decide solicitarlo al servidor y para algunos está decidiendo leer desde archivos almacenados (en caché). Por qué es esto ? Cada archivo tiene una fecha de caducidad, por lo

Si un archivo no está caducado, el navegador utilizará desde el caché (200 caché).

Si el archivo está vencido, el navegador solicita el servidor para un archivo. Archivo de verificación del servidor en ambos lugares (navegador y servidor). Si se encuentra el mismo archivo, el servidor rechaza la solicitud. Según el navegador de protocolo usa el archivo existente.

mira esta configuración nginx

location / {
    add_header Cache-Control must-revalidate;
    expires     60;
    etag on;

    ...
}

Aquí el vencimiento se establece en 60 segundos, por lo que todos los archivos estáticos se almacenan en caché durante 60 segundos. Por lo tanto, si vuelve a solicitar un archivo en 60 segundos, el navegador lo leerá desde la memoria (200 de memoria). Si lo solicita después de 60 segundos, el navegador solicitará el servidor (304).

Supuse que el archivo no se cambia después de 60 segundos, en ese caso obtendría 200 (es decir, el archivo actualizado se obtendrá del servidor).

Por lo tanto, si los servidores están configurados con diferentes encabezados (políticas) de caducidad y caducidad, el estado puede variar.

En su caso, está utilizando cdn, el objetivo principal de cdn es la alta disponibilidad y la entrega rápida. Por lo tanto, usan varios servidores. Aunque parece que los archivos están en el mismo directorio, cdn podría usar varios servidores para proporcionarle contenido, si esos servidores tienen diferentes configuraciones. Entonces estos estados pueden cambiar. Espero eso ayude.

Answer 6

Los elementos con el código "200 (caché)" se cumplían directamente desde la memoria caché del navegador, lo que significa que las solicitudes originales de los elementos se devolvieron con encabezados que indican que el navegador podría almacenarlos en caché (por ejemplo, Expires fecha futura o Cache-Control: max-age encabezados de Cache-Control: max-age ), y que en el momento en que activó la nueva solicitud, esos objetos almacenados en la memoria caché aún se almacenaban en la memoria caché local y aún no habían expirado.

Los 304s, por otro lado, son la respuesta del servidor después de que el navegador ha verificado si un archivo fue modificado desde la última versión que había almacenado (la respuesta es "no").

Para un rendimiento web óptimo, lo mejor es configurar un futuro lejano Expires: o Cache-Control: max-age encabezado de Cache-Control: max-age para todos los activos, y luego cuando un activo necesita ser cambiado, cambiar el nombre de archivo real del activo o agregar una cadena de versión para las solicitudes de ese activo. Esto elimina la necesidad de realizar cualquier solicitud a menos que el activo haya cambiado definitivamente de la versión en caché (no es necesario para esa respuesta 304). Yahoo! tiene más pautas de rendimiento relacionadas con la caché , que incluyen asegurarse de que los ETags estén configurados correctamente.