Prompt y alcance
Un cliente solicita un recurso mediante negociación de contenido transparente y recibe HTTP 506 Variant Also Negotiates. El sistema cuenta con negociación estilo Apache, proxies inversos y cachés. Explique la semántica, el desencadenante del bucle, el diagnóstico, el comportamiento de la caché y el fallback.
Qué evalúa el entrevistador
- Saber que 506 proviene de la negociación de contenido transparente de RFC 2295.
- Distinguir un bucle de negociación de 406 Not Acceptable y 502 de proxy.
- Inspeccionar Alternates, Variant-Vary, TCN y metadatos relacionados.
- Definir límites de reintentos, almacenamiento en caché y degradación.
- Agregar detección de ciclos, observabilidad y filtros de control de despliegue (release gates).
Aclaraciones a solicitar primero
Confirmar Accept y Accept-Language, si el recurso es una lista de variantes, qué capa emite 506, si hay una caché de proxy involucrada y si es aceptable una representación fija. Asumir que una variante apunta de nuevo al recurso en negociación.
Marco de respuesta de treinta segundos
506 significa que la negociación transparente formó un bucle y el servidor no puede seleccionar una representación final. Rastree la cadena de respuesta y los metadatos de negociación para demostrar un ciclo en lugar de tratarlo como una falla genérica del upstream. El cliente no debe reintentar a ciegas con la misma configuración; puede solicitar una representación fija o desactivar la negociación. Limite la profundidad de negociación, repare las variantes y monitoree 506 frente a 406.
Análisis detallado paso a paso
1. Explicar la negociación transparente
RFC 2295 permite que un origen publique variantes, mientras que los clientes e intermediarios seleccionan una representación a partir de los encabezados de la solicitud. La solicitud debe converger eventualmente en un recurso concreto.
2. Identificar el bucle
Si una variante apunta a otro recurso que también requiere negociación transparente, la selección puede regresar al objeto original. Registre el URI del recurso, el URI de la variante, el proxy de negociación, el ID de solicitud y un conjunto de visitados; volver a visitar un nodo demuestra un ciclo.
3. Separar códigos de estado cercanos
406 significa que ninguna representación satisface las condiciones del cliente. 502 significa que una puerta de enlace recibió una respuesta de upstream no válida. Una investigación de 506 debe seguir el grafo de negociación, no solo el estado del borde final.
4. Diseñar el fallback del cliente
Reintentar con los mismos encabezados y configuración no puede eliminar el ciclo. Solicite una variante fija, omita la negociación transparente o muestre un mensaje de reparación. Reintente únicamente dentro de un presupuesto tras un cambio de configuración o una señal transitoria explícita.
5. Manejar claves de caché y Vary
Las claves de caché deben incluir las dimensiones de Vary utilizadas en la negociación; un 506 no debe convertirse en una respuesta duradera para cada representación. Siga Cache-Control para el almacenamiento en caché de errores y tenga en cuenta las entradas antiguas del proxy después de la reparación.
6. Reparar y asegurar el servidor
Construya un grafo de variantes antes del lanzamiento y ejecute detección de ciclos con límites de profundidad y tiempo. Devuelva un ID de correlación en lugar de la topología interna de URIs. Los proxies deben conservar el estado original, Via y los datos de rastreo para que las reescrituras no oculten la causa.
7. Validar y observar
Pruebe autociclos, ciclos de dos nodos, listas acíclicas profundas, diferentes encabezados Accept e idioma, cachés de proxy, despliegue y reversión. Monitoree 506/406, tiempo de negociación, fallback, aciertos de caché y duración de la reparación.
Respuesta de muestra de alta calidad
506 es el error de bucle de negociación transparente de RFC 2295. Cuando una variante apunta de nuevo a un recurso en negociación, el servidor no puede producir una representación final. Registraría el URI, la variante, el proxy y el ID de solicitud, utilizaría un conjunto de visitados para demostrar el ciclo y conservaría el estado original y el rastreo en cada salto.
Las mismas condiciones deben fallar rápidamente en lugar de reintentar. El cliente puede solicitar una variante fija. Antes del lanzamiento, el servidor construye el grafo de variantes, comprueba ciclos, limita la profundidad y el tiempo, y valida Vary y las claves de caché. La aceptación cubre cambios de encabezados e idioma, cachés de proxy, despliegue, reversión y la distinción respecto a 406.
Errores comunes
- Tratar 506 como 406 o 502.
- Inspeccionar solo el estado final del proxy en lugar del grafo de variantes.
- Reintentar indefinidamente la misma configuración de negociación.
- Omitir dimensiones de Vary en las claves de caché.
- Desplegar sin detección de ciclos ni límites de profundidad.
- Devolver URIs de variantes internas en los errores.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuál es la diferencia clave entre 506 y 406?
406 no tiene una representación aceptable. 506 significa que el proceso de negociación en sí entra en ciclo y no puede converger.
Pregunta de seguimiento 2: ¿Puede un cliente reintentar ante un 506?
No con una configuración sin cambios. Reintente solo después de una reparación o ante una señal transitoria explícita, dentro de un presupuesto.
Pregunta de seguimiento 3: ¿Cómo demuestra que un proxy cambió el estado?
Compare el rastreo por salto, Via, el estado original y los encabezados de negociación; reproduzca directamente contra el origen cuando sea necesario.
Pregunta de seguimiento 4: ¿Debe almacenarse el error en caché?
Siga Cache-Control y evite amplificar el bucle; purgue las entradas obsoletas afectadas después de la reparación.