http - open - whatsapp cache link
304 No modificado con 200(desde caché) (3)
"200 (desde el caché)" significa que el navegador encontró una respuesta en caché para la solicitud realizada. Entonces, en lugar de hacer una llamada de red para obtener ese recurso del servidor remoto, simplemente hizo uso de la respuesta en caché.
Ahora estas respuestas en caché tienen un tiempo de vida asociado con ellas. Con el tiempo, las respuestas pueden volverse obsoletas. Y si no se permite que estos se sirvan obsoletos (consulte la sección 4.2.4 - RFC7234 ), el navegador debe comunicarse con el servidor remoto y verificar si estas respuestas en caché siguen siendo válidas o no. El código de estado de la respuesta 304 es la forma en que los servidores informan al navegador que la respuesta no ha cambiado y sigue siendo válida.
Si el navegador recibe una respuesta 304 , puede "refrescar" las respuestas obsoletas relevantes. Y las solicitudes subsiguientes al recurso pueden nuevamente ser servidas desde el caché del navegador sin verificar con el servidor remoto (hasta que la respuesta se vuelva obsoleta nuevamente).
Estoy tratando de entender cuál es exactamente la diferencia entre "estado 304 no modificado" y "200 (desde caché)"
Estoy recibiendo 304 en archivos javascript que cambié la última vez. ¿Por qué pasó esto? Gracias por la ayuda.
https://sookocheff.com/post/api/effective-caching/ es una excelente fuente para formar el entendimiento requerido alrededor de estos 2 códigos de estado HTTP.
Después de leer esto a fondo, tuve esta comprensión
En el uso típico, cuando se recupera una URL, el servidor web devolverá la representación actual del recurso junto con su valor ETag correspondiente, que se coloca en el campo "ETag" del encabezado de respuesta HTTP. El cliente puede entonces decidir almacenar en caché la representación, junto con su ETag. Más adelante, si el cliente desea recuperar el mismo recurso de URL, primero determinará si la versión local en caché de la URL ha caducado (a través de los encabezados Cache-Control y Expirar). Si la URL no ha caducado, recuperará el recurso local en caché. Si determinó que la URL ha caducado (está obsoleta), el cliente se pondrá en contacto con el servidor y enviará su copia previamente guardada de la ETag junto con la solicitud en un campo "Si no hay coincidencia". (Fuente: https://en.wikipedia.org/wiki/HTTP_ETag )
Pero incluso cuando el tiempo de vencimiento para un activo se establezca en el futuro, el navegador todavía puede alcanzar el servidor para un GET condicional usando ETag según el encabezado "Variar". Detalles en el encabezado de ''vary'': https://www.fastly.com/blog/best-practices-using-vary-header/
304 Modificado
A 304 No modificado significa que los archivos no se han modificado desde la versión especificada por "If-Modified-Since" o "If-None-Match".
200 ok
Esta es la respuesta que obtendrás si una solicitud HTTP funciona. Las solicitudes GET tendrán algo relacionado con los archivos. Una solicitud POST tendrá algo que contenga el resultado de la acción.
¡Feliz codificación!
Lyfe