Introducción
Los códigos de respuesta HTTP son herramientas esenciales que ayudan a comunicar el estado de una solicitud entre un cliente y un servidor. Uno de estos códigos es 304 Not Modified, que indica que un recurso no ha sido modificado y puede ser recuperado de la caché. Este artículo examinará más de cerca el código 304 Not Modified y su uso.
Antecedentes
El código 304 Not Modified se utiliza junto con el método de solicitud “GET condicional”, que permite a un cliente recuperar un recurso sólo si ha sido modificado desde la última vez que se solicitó. Cuando el servidor recibe una solicitud GET condicional, comprueba la ayuda en cuestión y compara su estado actual con el estado de la copia almacenada en caché en el cliente. Si el recurso no ha sido modificado, el servidor devolverá un código 304 Not Modified, junto con las cabeceras correspondientes, indicando que el cliente puede utilizar la copia en caché.
Este mecanismo está definido en la especificación HTTP/1.1, que especifica que “la respuesta 304 NO DEBE contener un cuerpo de mensaje, por lo que siempre termina con la primera línea vacía después de los campos de cabecera”.
Ejemplos de uso
Un caso de uso cotidiano del código 304 Not Modified es el de las aplicaciones web en las que recursos como imágenes y hojas de estilo se solicitan con frecuencia pero no cambian a menudo. Utilizando el código 304 Not Modified, el servidor puede evitar malgastar ancho de banda y recursos enviando los mismos datos varias veces. Además, esto puede mejorar el rendimiento general de la aplicación web.
Otro ejemplo es el desarrollo de API RESTful, en el que se pretende que determinados puntos finales devuelvan los mismos datos si el servidor no los ha modificado. Esto puede ahorrar recursos del servidor y batería, datos y capacidad de procesamiento del cliente.
Un servidor puede configurarse para devolver un código 304 Not Modified comprobando y gestionando las peticiones “GET condicionales”. Una petición GET condicional es un tipo de petición en la que el cliente incluye cabeceras como “If-Modified-Since” o “If-None-Match” para indicar que ya tiene una copia en caché del recurso y que sólo quiere recuperarlo si ha sido modificado. El servidor puede entonces comparar el estado de la ayuda solicitada con la forma de la copia en caché y devolver un código 304 Not Modified si el recurso no ha sido modificado.
Ejemplos
Estos son algunos ejemplos de cómo comprobar y manejar una respuesta 304 Not Modified en diferentes lenguajes de programación:
Java:
// Check for a 304 Not Modified response
if (response.getStatusLine().getStatusCode() == HttpStatus.SC_NOT_MODIFIED) {
// Use the cached copy of the resource
} else {
// Retrieve the updated resource }
Python
# Check for a 304 Not Modified response
if response.status_code == 304:
# Use the cached copy of the resource
else:
# Retrieve the updated resource
Javascript
// Check for a 304 Not Modified response
if (response.status === 304) {
// Use the cached copy of the resource
} else {
// Retrieve the updated resource
}
Aplicación
Para implementar el código 304 Not Modified, un servidor debe estar configurado para comprobar y gestionar peticiones GET condicionales. Esto puede hacerse utilizando varias configuraciones de servidor web o frameworks. Además, muchos lenguajes y marcos de programación, como Java, Python y Ruby on Rails, disponen de bibliotecas o módulos que pueden simplificar el manejo del código 304 Not Modified. Por ejemplo, en Apache, los módulos mod_cache y mod_headers pueden utilizarse para controlar la caché y las cabeceras, respectivamente.
Solución de problemas
Cuando se trabaja con el código 304 Not Modified, un problema común es que la copia almacenada en caché en el cliente puede ser obsoleta o incorrecta. Para evitarlo, el servidor debe asegurarse de que se envían las cabeceras adecuadas, como Last-Modified y ETag, con cada respuesta. Además, el servidor debe estar configurado para enviar una respuesta completa cuando se haya modificado el recurso.
Otro problema que puede ocurrir es que el servidor no esté gestionando correctamente la petición GET condicional. Para solucionar este problema, los desarrolladores pueden utilizar herramientas como la pestaña Red de las herramientas de desarrollo del navegador para inspeccionar las cabeceras de la solicitud y la respuesta.
Problemas comunes
Cuando se trabaja con el código 304 Not Modified, pueden surgir algunos problemas comunes:
- La copia en caché es antigua o incorrecta: Una de las principales ventajas del código 304 Not Modified es que permite a los clientes utilizar una copia en caché de un recurso en lugar de solicitarla al servidor. Sin embargo, si la copia en caché es obsoleta o incorrecta, puede provocar problemas como enlaces rotos o que se muestre un contenido incorrecto. Para evitarlo, el servidor debe asegurarse de que se envían las cabeceras adecuadas, como Last-Modified y ETag, con cada respuesta. Además, el servidor debe estar configurado para enviar una respuesta completa cuando se haya modificado el recurso.
- La solicitud GET condicional no se gestiona correctamente: Otro problema que puede ocurrir es que el servidor no gestione correctamente la solicitud GET condicional. Esto puede ocurrir si el servidor no está configurado para comprobar y gestionar peticiones GET condicionales o si hay un error en la implementación. Para solucionar este problema, los desarrolladores pueden utilizar herramientas como la pestaña Red de las herramientas de desarrollo del navegador para inspeccionar las cabeceras de la solicitud y la respuesta.
- Almacenamiento en caché involuntario: Algunos sistemas pueden no comportarse como es debido al almacenar en caché, provocando datos obsoletos o incoherentes. Esto es especialmente cierto en situaciones de alta concurrencia y baja validez de la caché. Para asegurarse de que esto no ocurra, es aconsejable controlar cuidadosamente la validez de la caché y cómo se comporta el sistema bajo diferentes cargas.
- Respuestas 304 incorrectas: Aunque el sistema se comporte según lo previsto, el error humano siempre puede dar lugar a respuestas 304 incorrectas. Esto puede ocurrir cuando un desarrollador considera erróneamente que un recurso no ha sido modificado, aunque sí lo haya sido. Para evitarlo, se recomienda contar con un proceso adecuado de revisión y prueba antes de implantar los cambios.
- Las cabeceras Cache-Control no están configuradas correctamente: Las cabeceras de respuesta HTTP como Cache-Control y Expires deben configurarse correctamente para indicar al cliente y a las cachés intermedias cuándo deben actualizar sus copias en caché del recurso. Una configuración incorrecta de estas cabeceras puede dar lugar a datos obsoletos o a un tráfico de red innecesario.
- Inconsistencia entre la caché del navegador y la del servidor: cuando se utiliza la caché del navegador, es esencial tener en cuenta las posibles inconsistencias entre la caché del cliente y la del servidor. Los desarrolladores también deben asegurarse de que la aplicación gestiona adecuadamente la caché del navegador y de que ésta es coherente con la del servidor.
Para solucionar estos problemas y evitarlos, es esencial contar con una supervisión y un registro adecuados, conocer las diferentes cabeceras y disponer de un proceso de pruebas exhaustivo para garantizar el comportamiento correcto del código 304 Not Modified.
Conclusión
El código 304 Not Modified es una herramienta esencial para reducir el uso del ancho de banda y mejorar el rendimiento de las aplicaciones web y las API. Los clientes pueden recuperar recursos de forma eficaz sin solicitar datos sin modificar utilizando el código 304 Not Modified junto con el método de solicitud “GET condicional”. Como desarrollador, es esencial comprender e implementar este código para reducir la carga del servidor y mejorar la experiencia del usuario.
Referencias: Especificación HTTP/1.1 (RFC 7232)
