Hace unos días llegó al correo un mensaje, de nuestro compañero Beni, en el que hablaba de lo bien y lo llamativo de cómo se había gestionado un error 522 en el uso de una aplicación web.
Casualmente me había encontrado con un post, en el blog Kabytes, que hablaba casi del mismo asunto: el mantenimiento y tratamiento de los errores en un portal. Así que aunque a priori no es mi fuerte me decidí a informarme un poco más acerca de este tema.
Muchas son las veces que navegando por la red nos encontramos con un código de error HTTP 404 Not Found o HTTP 503 Service Unavailable.
Este tipo de mensajes suelen producirse cuando se están realizando labores de mantenimiento del portal y se ha dejado offline o bien cuando éste ha dejado de funcionar y no hemos sido capaces de gestionar el error.
Si además es una empresa la que está detrás de ese desarrollo, el tratamiento debe extremarse puesto que además de evitar molestias a los usuarios se está mostrando el grado de atención, cuidado y por qué no del mimo con el que se ha trabajado.
Cuando el portal entra en alguno de los puntos arriba referidos, mantenimiento o error, debemos cumplir con dos objetivos:
- Comunicar a los posibles visitantes/usuarios que el sitio no está disponible.
- Notificar a los spiders (arañas) de los buscadores para que no tomen en cuenta el nuevo estado del portal.
El primero de los objetivos se suele cumplir básicamente con la inclusión de algún mensaje informativo donde se explica que el sitio se halla en mantenimiento y que volverá a la normalidad en el menor tiempo posible.
Para alcanzar el segundo se suele hacer uso de los códigos de estado HTTP.
¿Pero son todos estos estados válidos? Mejor dicho, ¿cuál sería el estado óptimo?
Para empezar deberíamos definir que es una araña web.
Spider o araña web. Una araña web (o araña de la web) es un programa que inspecciona las páginas del World Wide Web de forma metódica y automatizada. Uno de los usos más frecuentes que se les da consiste en crear una copia de todas las páginas web visitadas para su procesado posterior por un motor de búsqueda que indexa las páginas proporcionando un sistema de búsquedas rápido. Las arañas web suelen ser bots (el tipo más usado de éstos).
Las arañas web comienzan visitando una lista de URLs, identifica los hiperenlaces en dichas páginas y los añade a la lista de URLs a visitar de manera recurrente de acuerdo a determinado conjunto de reglas. La operación normal es que se le da al programa un grupo de direcciones iniciales, la araña descarga estas direcciones, analiza las páginas y busca enlaces a páginas nuevas. Luego descarga estas páginas nuevas, analiza sus enlaces, y así sucesivamente.
Precisamente por eso hay que tener especial cuidado con el código que se usa, ya que la araña puede entender que hay contenido nuevo o modificado e intentar actualizar la información que tenía de nuestro portal a la información que tendríamos en ese instante que no sería otro que el mensaje de portal en mantenimiento.
Esto evidentemente no es lo que nos interesa.
Para conocer más acerca de las arañas es muy recomendable ver este vídeo: https://www.youtube.com/watch?feature=player_embedded&v=BNHR6IQJGZs#t=38
Códigos como HTTP 200 OK o 404 Not Found, pese a populares, no son las mejores opciones.
En cambio, los amigos de Kabyte nos proponen otra solución:
Código HTTP 503 Service Unavailable.
10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
El estado 503 indica que el servidor no puede procesar la solicitud debido a una sobrecarga o bien al mantenimiento del servidor.
Se trata de una condición temporal que a la que se le dará solución en un plazo de tiempo.
Si se conoce, la duración de la demora puede ser indicado en una cabecera Retry-After.
Si no se indica el valor de Retry-After, el cliente debe manejar la respuesta como lo haría con una respuesta 500.
¿Para qué vale entonces Retry-After? Simple, mediante la opción Retry-After se le indica a la araña del buscador que vuelva a pasar nuevamente a verificar/actualizar el contenido del portal en el tiempo que se le ha detallado, fecha en la que esperamos tener nuestro portal de nuevo en funcionamiento.
Para indicar el valor de Retry-After bastaría con que añadiésemos esta línea en un fichero PHP.
Para ver el listado de códigos de estado HTTP (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)