Resumen

  • HTTP 511 indica que el equipo debe satisfacer a la red de acceso antes de obtener conectividad; corresponde a un proxy interceptor, no al origen solicitado.
  • La respuesta debe enlazar a un recurso de acceso separado y no presentar un reto bajo la identidad del origen. Así limita confusión, pero no vuelve fiable la interceptación ni resuelve TLS.

La autoridad equivocada emitió la respuesta

Una aplicación meteorológica se une a una red nueva y solicita datos al servicio que conoce. Recibe una página de registro del hotel. Los bytes llegan por la conexión HTTP, pero el hotel no es el origen meteorológico y la página no responde a la operación.

Un navegador puede mostrar la anomalía a una persona. Un calendario, actualizador o cliente API puede interpretar el HTML como respuesta del origen, guardarlo o seguir una redirección. La red sustituyó el mensaje de otra autoridad por su propia condición.

RFC 6585 definió en 2012 511 Network Authentication Required. El cliente debe interactuar para ganar acceso a la red. El emisor importa: no es el origen nombrado, sino un proxy interpuesto para controlar conectividad.

Admisión de red no es autenticación de aplicación

La palabra autenticación cubre relaciones distintas. Un origen puede pedir credenciales para un recurso. Una red puede exigir pago, condiciones u otra interacción antes de transportar tráfico. Sus mandatos no se mezclan.

RFC 6585 dice que el origen no debería producir 511. Para la aplicación existen semánticas normales de autenticación y autorización. El 511 describe una precondición del camino.

El portal no obtiene derecho a imitar al servicio porque puede bloquear paquetes. El origen no asume el contrato del portal. El cliente entiende que cambiar su contraseña de aplicación no resolverá esta rama.

Un enlace, no un formulario bajo nombre ajeno

La representación 511 debería incluir un enlace al recurso donde se satisface la condición. No debería contener el reto ni la interfaz de acceso.

El navegador presenta la respuesta en el contexto de la URL solicitada. Un formulario insertado puede parecer propiedad del origen; un reto puede hacer creer que ese sitio pide el secreto.

El enlace mueve la interacción a un recurso con nombre propio. Es una frontera mejor, no una garantía. El cliente debe mostrar el host, validar el certificado TLS y permitir que el usuario decida. El portal sólo puede pedir credenciales que tenga autoridad para recibir.

511 comunica un traspaso, no completa la solicitud inicial. Tras la interacción, el cliente vuelve a la operación contra el origen real.

Los clientes sin navegador revelaron el daño

RFC 6585 presenta 511 como mitigación del daño causado por portales cautivos, en especial para software no navegable. No promueve la interceptación.

Un actualizador que espera un manifiesto puede leer HTML como metadatos corruptos. Un cliente de sincronización puede conservar estado falso. La redirección no restaura autoridad: el software puede seguirla y procesar el portal dentro del flujo original.

Cuantos más protocolos usan HTTP, más fronteras cruza una sustitución general. Un estado distinto permite que un cliente robusto suspenda el trabajo del origen en vez de mutarlo, almacenarlo o repetirlo a ciegas.

El caché no puede convertir cautividad en estado del origen

RFC 6585 prohíbe almacenar 511. La condición pertenece a una red conectada, un estado de admisión y un momento. Una copia podría seguir al cliente después de abrir el acceso o cambiar de red, y aparentar que describe al origen.

El sistema de admisión actual puede crear un veredicto nuevo. El caché no tiene autoridad para prolongar la interceptación.

TLS rechaza la identidad prestada

Con HTTP en claro, el intermediario puede sustituir la respuesta. Con HTTPS, el cliente autentica primero el nombre del servidor. El portal no posee el certificado del origen; RFC 6585 señala que la interceptación produce un error de certificado.

511 no puede aparecer tras una negociación TLS que el portal no puede completar honestamente. Ignorar la alerta entregaría a la red la identidad del origen.

El intermediario también puede observar credenciales HTTP o interferir con cookies. Esos riesgos existen con o sin 511. Un error preciso no sanea un camino inseguro.

De la sorpresa a un estado anunciado

RFC 8952 separa equipo, aprovisionamiento, API, portal de usuario y dispositivo de aplicación. RFC 8908 define la consulta HTTPS.

Al unirse, el cliente recibe la URI de la API en lugar de sondear un origen cualquiera en claro. Valida el certificado, consulta su estado cautivo y recibe un booleano obligatorio y, cuando corresponde, una URL TLS del portal.

Después de satisfacer las condiciones, vuelve a consultar para verificar que terminó la cautividad. Un formulario o redirección exitosos no bastan. API y enforcement deben referirse al mismo equipo.

La arquitectura no elimina portales heredados y la identidad compartida sigue siendo difícil. Pero hace que la red hable desde un nombre que puede operar, sin convertir al origen meteorológico en superficie accidental de descubrimiento.

La verdad limitada de 511

511 no autentica el portal, no legitima la interceptación, no vence TLS y no prueba consentimiento. Tampoco sustituye 401 o 403 en el origen. Sólo nombra una demanda del camino de acceso y evita que se convierta en contenido reutilizable del destino.

El principio perdura: cada poder debe hablar desde su propia identidad. La red controla transporte; no necesita tomar prestada la voz del destino para explicarlo.

Fuentes