300 Multiple Choices: el código que casi nunca verás

Para qué se diseñó el código

HTTP admite la negociación de contenido: la misma URL puede tener varias representaciones que se diferencian por formato, idioma o codificación. Normalmente el servidor decide, usando las cabeceras Accept, Accept-Language y Accept-Encoding del cliente, y devuelve la elegida con un 200. Eso es negociación dirigida por el servidor, y es lo que hace la web.

300 Multiple Choices cubre el otro enfoque, la negociación dirigida por el agente. En lugar de elegir, el servidor responde con una lista de las representaciones disponibles y deja que el cliente o el usuario elija. La respuesta puede incluir una cabecera Location que nombra la opción preferida del servidor, que un cliente es libre de seguir.

Por qué casi nunca ves uno

El estándar nunca especificó un formato legible por máquina para la lista de opciones. Sin un formato acordado no hay nada que pueda interpretar un navegador, así que ningún navegador convencional implementa una interfaz de selección para un 300. Los navegadores normalmente muestran el cuerpo de la respuesta como una página normal en su lugar, o siguen la cabecera Location si hay una presente, lo que hace que el 300 se comporte como una redirección débil. Los frameworks de aplicación y las CDN no lo emiten en sus configuraciones por defecto, y la negociación dirigida por el servidor resuelve el mismo problema de forma invisible y mejor, así que nadie tiene motivo para cambiar.

Un 300 aún aparece en unos pocos sitios:

• El mod_negotiation de Apache con MultiViews activado, cuando varios archivos coinciden con una petición como /logo y el módulo no puede ordenarlos. Genera una lista HTML de candidatos.
• APIs escritas a mano que devuelven deliberadamente una lista JSON de URLs de recursos alternativos, usando 300 como una pista semántica sin esperar que ningún cliente lo maneje de forma nativa.
• Baterías de pruebas y herramientas de conformidad de protocolo que ejercitan cada código de estado definido.

Por qué la gente busca el código de estado 300

La mayoría de las búsquedas de "código de estado 300" no tratan en absoluto de un 300. El número es el inicio de la familia de redirecciones, así que la gente que vio una redirección en una herramienta de navegador, un registro o un rastreador de SEO y recordó "un trescientos y algo" busca primero el 300. Lo que normalmente tienen es:

• Un 301, una redirección permanente, reportado por un rastreador de SEO como parte de una cadena.
• Un 302, una redirección temporal, el que emiten por defecto muchos frameworks.
• Un 304, que es una respuesta de validación de caché y no una redirección en absoluto.
• Un resumen de rastreador que agrupa todo bajo un encabezado "3xx", que luego se lee como "300".

Si estás intentando averiguar qué redirección devuelve una URL, la guía 301 frente a 302 es la que necesitas.

Cómo comprobar si de verdad tienes un 300

1. Pide las cabeceras sin seguir ninguna redirección y lee el número exacto:

   curl -sI https://example.com/some-path | grep -Ei "^(HTTP|location|link|alternates)"

   Un 300 genuino muestra HTTP/1.1 300 Multiple Choices. Cualquier otra cosa es un código distinto y una guía distinta.
2. Si de verdad es un 300 y no era tu intención, mira primero Apache. Desactivar MultiViews para ese directorio, o darle al archivo una extensión explícita en la URL, elimina la ambigüedad que dispara la negociación.
3. Si quieres que elija el servidor, mantén la negociación dirigida por el servidor: devuelve 200 con la representación seleccionada y una cabecera Vary que nombre las cabeceras de petición sobre las que negociaste, para que las cachés guarden las variantes por separado.
4. Si quieres enviar a los clientes a otro sitio, usa una redirección real. Los traslados permanentes llevan 301 u 308, los temporales llevan 302 o 307. No uses 300 como redirección, porque los clientes no están obligados a seguirlo.
5. Arregla la ambigüedad en el origen. Un 300 casi siempre significa que dos archivos o dos rutas compiten por la misma URL, y la solución duradera es hacer la URL inequívoca.

Detectar un 300 inesperado tras un despliegue

Un 300 inesperado suele llegar con una actualización de servidor o un cambio de configuración, y nadie lo nota: la página puede seguir viéndose más o menos bien en un navegador mientras los rastreadores y los clientes de API reciben una respuesta que no pueden usar. Una comprobación externa que registra el código de estado exacto de cada URL saca el cambio a la luz en la primera ejecución tras el despliegue. HostTracker monitoriza sitios web desde 2004 y ejecuta comprobaciones desde más de 300 puntos de control en 158 ciudades. Comprueba lo que devuelve una URL ahora mismo con la herramienta de comprobación HTTP, o lee la guía completa de la familia de redirecciones 3xx.