HTTP 407 sin un desafío Proxy-Authenticate utilizable

Un cliente no puede elegir un mecanismo de autenticación a partir de un número de estado por sí solo. La respuesta del proxy debe describir qué acepta.

HTTP exige que un proxy que genera un 407 envíe un desafío Proxy-Authenticate. Para un servicio Basic, un ejemplo sencillo es:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

El estado numérico, el nombre de la cabecera y la sintaxis específica del esquema importan por igual. Una página de error de marca con la palabra authentication en su cuerpo no sustituye a la cabecera. Las implementaciones personalizadas también deben enviar una respuesta HTTP 407 completa, incluido el terminador de la cabecera y el encuadre del cuerpo.

Inspeccione la respuesta que llegó a este cliente

Capture los campos de estado y desafío después de eliminar los valores secretos. Es posible que un intermediario haya transformado la respuesta, o que un proxy personalizado haya construido un desafío no válido. Compare esa evidencia con el registro de transacciones del propio proxy.

Si el servicio envía 405 u otro error en su lugar, no reetiquete todas esas respuestas como 407 dentro de un cliente personalizado. Ocultaría fallos reales de la política de métodos y seguiría sin tener una negociación de esquema fiable. Repare el comportamiento del servicio o use su ruta de autenticación compatible documentada.

Los desafíos múltiples también requieren un analizador HTTP real. Una coma puede separar parámetros o desafíos; dividir toda la cabecera a ciegas por comas puede corromper un realm entre comillas. Use la implementación de autenticación compatible del cliente en lugar de una sucesión de reemplazos de cadenas.

Solo cuando el desafío es utilizable tiene sentido investigar por qué el proveedor de credenciales no devolvió una cuenta.