Entrevista general: ¿Qué debe contener una respuesta HTTP 451 y cómo deben manejarla los clientes?

Planteamiento y contexto

Este planteamiento sobre fundamentos de redes y APIs se adapta a roles de backend, plataforma e infraestructura. Se deniega un recurso debido a un requerimiento legal, y el bloqueo puede ocurrir en el origen, CDN, ISP o motor de búsqueda. El objetivo es explicar cuándo es apropiado 451, cómo brindar transparencia y por qué un bloqueo legal no es un error de permisos ordinario ni una interrupción reintentable.

Qué está evaluando el entrevistador

• ¿Puedes distinguir 451, 403, 404 y 5xx según su semántica y responsabilidad?
• ¿Sabes que 451 indica una exigencia legal sin demostrar que el recurso exista?
• ¿Puedes combinar el cuerpo de la respuesta, Link: rel="blocked-by", el almacenamiento en caché y el comportamiento del proxy de forma correcta?
• ¿Consideras la privacidad, las divulgaciones engañosas, la usabilidad del cliente, los registros de auditoría y la verificación multirregión?

Preguntas de clarificación que debes hacer

Confirma quién aplica realmente el bloqueo, si el resultado varía por región, si la base legal puede divulgarse, si hay una caché compartida intermediaria y si el cliente es un navegador, una aplicación móvil o un consumidor de API. Si el usuario simplemente carece de permisos, usa 401 o 403; si el recurso no existe, no lo cambies a 451 simplemente para ocultar detalles de implementación. Si la divulgación está prohibida, define la evidencia pública y la interna por separado.

Marco de respuesta de 30 segundos

Usaría 451 solo cuando el servicio deniegue el acceso debido a una exigencia legal, y colocaría la base legal y el alcance en un cuerpo auditable. Si una CDN u otro intermediario aplica el bloqueo, Link con rel="blocked-by" identifica a la entidad que lo ejecuta, no a la autoridad que emitió la orden. Elegiría el comportamiento de la caché según la volatilidad regional y de la política, mostraría a los clientes un estado claro de no disponible y evitaría reintentos automáticos o promesas de que otra red funcionará. Finalmente, verificaría el comportamiento del origen, proxy, caché y regiones en conjunto.

Análisis detallado paso a paso

1. Clasificar la semántica. 451 significa que el servidor deniega un recurso debido a una exigencia legal; 403 significa que el solicitante identificado no tiene permiso, y 404 significa que el recurso no existe o su existencia se oculta intencionalmente. 451 no demuestra que el recurso exista y no es una falla técnica.
2. Identificar la entidad que ejecuta el bloqueo. El origen, la CDN, el ISP, el servicio DNS o el motor de búsqueda pueden ser el bloqueador real. Dicha entidad se identifica a sí misma en un encabezado Link con rel="blocked-by"; la autoridad o la explicación de la política corresponde al cuerpo o a la página de políticas, no a esa relación.
3. Diseñar la respuesta. Explica la base legal o de política, la parte emisora, la región afectada o clase de recurso, y una ruta de apelación o ayuda. Si la divulgación genera un riesgo adicional, publica solo lo necesario mientras mantienes la base completa y el aprobador en los registros internos de auditoría.
4. Manejar el almacenamiento en caché. La RFC 7725 permite que 451 sea almacenable en caché por defecto, por lo que un estado legal o regional que cambie frecuentemente necesita un Cache-Control explícito, un TTL corto o no-store. Una clave de caché compartida debe incluir cada dimensión que afecte el bloqueo para que la respuesta de una región no se filtre a otra.
5. Definir el comportamiento del cliente. Un navegador muestra un estado claro de contenido restringido. Un cliente de API trata 451 como un error de política no reintentable, preservando el estado, los detalles del bloqueo y el ID de solicitud. No debe reescribirlo como 500 ni evadir automáticamente la política a través de un proxy o VPN.
6. Verificar y monitorear. Compara el estado, cuerpo, encabezados y aciertos de caché entre solicitudes directas al origen, CDN, múltiples regiones, con caché caliente y caché fría, y diferentes clientes. Registra eventos de auditoría, versiones de reglas, entidad ejecutora y tiempo de revocación; purga las cachés afectadas cuando cambie la política.

Ejemplo de una respuesta sólida

Primero confirmaría que la denegación sea genuinamente legal. Un problema de permisos devuelve 403 y un recurso faltante devuelve 404; 451 comunica un bloqueo legal sin asegurar que el recurso exista. Debido a que el origen o la CDN pueden aplicarlo, identificaría al bloqueador real en Link:

HTTP/1.1 451 Unavailable For Legal Reasons
Content-Type: application/problem+json
Cache-Control: private, max-age=300
Link: <https://blocker.example/policy/123>; rel="blocked-by"

{
  "status": 451,
  "title": "Unavailable For Legal Reasons",
  "detail": "Access is restricted in this region under the cited policy.",
  "policy_id": "policy-123",
  "request_id": "req-7f2"
}

El cuerpo brinda al usuario suficiente explicación y una ruta de apelación; la auditoría interna retiene la base legal completa, la decisión regional, la versión de la regla y el operador. Dado que 451 es almacenable en caché por defecto, la clave de caché incluye la región y la versión de la regla, con un TTL corto o sin almacenamiento cuando el estado de la política cambia con rapidez. El cliente presenta una restricción de política y detiene los reintentos automáticos. Las pruebas cubren el origen, CDN, aciertos de caché, cambios de región, revocación de reglas y casos donde la divulgación es limitada.

Errores comunes

• Devolver 451 para cada denegación → los permisos, la ausencia y los bloqueos legales se vuelven indistinguibles → clasifica la razón antes de elegir 401, 403, 404, 451 o 5xx.
• Poner la autoridad legal en blocked-by → la semántica de la relación es incorrecta → identifica allí la entidad que ejecuta el bloqueo y explica la política por separado en el cuerpo.
• Ignorar la capacidad de almacenamiento en caché por defecto → el resultado de una región se comparte con otra → diseña la clave de caché, el TTL y cualquier comportamiento no-store requerido.
• Reintentar automáticamente 451 → las solicitudes repetidas no pueden cambiar el estado de la política → trátalo como un error de política no reintentable con texto de ayuda procesable.
• Tratar 451 como prueba de que un recurso existe → puede filtrar información del sitio → establece explícitamente que el estado no confirma la existencia.

Preguntas de seguimiento y respuestas

¿Qué sucede si la exigencia legal prohíbe divulgar la disposición exacta?

Devuelve solo la restricción necesaria y el ID de solicitud; no inventes detalles. Mantén la base legal, el aprobador y la versión en los registros internos de auditoría. El cliente aún debe saber que es una restricción de política y no una falla de red.

¿Se puede almacenar en caché una respuesta 451?

Sí. La RFC 7725 establece que es almacenable en caché por defecto, pero la volatilidad y la sensibilidad determinan la política. Si la región, el grupo de usuarios o la versión de la regla cambian el resultado, usa la clave de caché correcta y un TTL corto, posiblemente no-store, y purga las cachés cuando se revoque el bloqueo.

La CDN devuelve 451 mientras que el origen devuelve 200. ¿Cuál es el bloqueador?

La CDN es la entidad que realmente deniega la solicitud y debe aparecer en blocked-by; el registro del origen debe mostrar que no realizó dicho bloqueo. Verifica los estados directo al origen, CDN y caché por separado para no confundir las capas.