Resumen

  • En RFC 2774, una petición con extensiones obligatorias cambiaba PUT por M-PUT o GET por M-GET, de modo que un servidor ajeno al marco rechazara el método en vez de ignorar la condición y producir un falso éxito.
  • El receptor compatible devolvía 510 cuando no podía satisfacer la política de extensión y Ext o C-Ext cuando había entendido y obedecido todo; el experimento terminó como Historic y sus identificadores figuran hoy como obsoletos.

Dos operaciones iguales en bytes, distintas en significado

Un cliente quiere almacenar un documento, pero exige que una extensión aplique una regla adicional. El servidor moderno reconoce la declaración y cumple ambas partes. El antiguo reconoce PUT, descarta los campos desconocidos y almacena los bytes sin la regla. Los dos pueden contestar 200 OK.

El segundo resultado no es un fallo de transporte. Es algo más difícil de detectar: una operación válida según el vocabulario antiguo y fallida según el contrato que el cliente creyó imponer. La tolerancia a novedades ha convertido la ignorancia en una respuesta tranquilizadora.

La propuesta experimental publicada en febrero de 2000 atacó justamente ese punto. Una extensión obligatoria no podía viajar detrás de un método normal. El emisor añadía M- al nombre: M-GET, M-PUT u otra forma equivalente. Quien no conocía RFC 2774 veía un método desconocido y tenía que fallar antes de ejecutar la versión reducida de la petición.

Incompatibilidad deliberada

Para un receptor compatible, el prefijo abría un procedimiento estricto. Primero debía reunir todas las declaraciones obligatorias, tanto las dirigidas al destino final como las de la conexión inmediata. Después comprobaba si podía aplicarlas a ese mensaje. Si faltaba soporte, respondía 510. Solo si superaba esa prueba podía ejecutar las extensiones y el método HTTP subyacente.

La especificación prohibía considerar satisfecha una petición sin entender y obedecer cada declaración obligatoria. La incompatibilidad era una barrera de seguridad semántica: mejor un error explícito que un éxito cuyo contenido contractual había desaparecido.

Obligatoria o opcional, final o por salto

RFC 2774 organizaba las declaraciones en una matriz de dos por dos. Man y Opt eran de extremo a extremo; C-Man y C-Opt se aplicaban al siguiente participante de la conexión. Cada una podía ser obligatoria u opcional.

La matriz aclaraba quién tenía autoridad para actuar. Un proxy no se convertía en destinatario de una condición final por el mero hecho de verla. Una condición por salto, en cambio, pertenecía a esa conexión y en HTTP/1.1 debía quedar protegida por Connection junto con sus campos asociados.

Las extensiones se identificaban mediante un URI globalmente único o, bajo una regla más estrecha, un nombre de campo definido por un estándar. Una declaración podía reservar un prefijo numérico como 16; los campos 16-... quedaban vinculados a esa instancia. Así se evitaban choques de nombres sin permitir que una extensión se apropiara de todo el espacio de cabeceras.

510 señalaba una política aún incumplida

510 Not Extended no significaba que el servidor estuviera caído. La sección 7 lo describía como el incumplimiento de la política de acceso del recurso. La respuesta debía aportar la información necesaria para construir una petición extendida aceptable.

Si el cliente era capaz de añadir las extensiones ausentes, podía modificar y repetir su solicitud. Si no, el cuerpo servía como diagnóstico. También recibía 510 un método M- sin declaraciones obligatorias: exigir semántica reforzada sin decir cuál era una contradicción del propio mensaje.

El código permitía separar tres estados que un 200 ordinario no distinguía: el receptor no entiende el marco; entiende el marco pero no satisface una extensión; o comprende y ejecuta todas las condiciones.

El éxito debía demostrar cumplimiento

Cuando el destinatario sí cumplía, la respuesta incluía una señal específica. Ext confirmaba todas las declaraciones obligatorias de extremo a extremo. C-Ext confirmaba las correspondientes al salto. No transportaban resultados de la aplicación; eran acuses de que la capa semántica declarada había sido atendida.

Su alcance era limitado. No certificaban que la extensión fuese segura ni que el resultado empresarial fuese correcto. Aportaban una pieza de evidencia: el éxito pertenecía al contrato extendido y no solo al método base.

El camino estaba lleno de lugares donde perder significado

Los proxies debían conservar el prefijo M- y las declaraciones finales. Las condiciones de conexión tenían que terminar en el salto adecuado. Los cachés no podían reutilizar una respuesta creada bajo una extensión para otra petición que careciera de ella.

Por eso la especificación añadió reglas detalladas. Una respuesta que satisfacía una condición final llevaba Cache-Control: no-cache="Ext"; para intermediarios HTTP/1.0 también debía parecer ya caducada mediante Expires. Si la representación dependía de un campo con prefijo numérico, Vary tenía que incluir tanto ese campo como la declaración que le daba sentido.

La complejidad no era gratuita: reflejaba todos los lugares donde una semántica podía separarse de sus datos. A la vez, mostraba el precio de coordinar en un único marco genérico a clientes, servidores, proxies, cachés y distintas generaciones de HTTP.

El final oficial del experimento

La nota original del IESG ya señalaba incertidumbre. La propuesta había solicitado ser estándar, pero recibió opiniones mixtas y no había consenso suficiente sobre cómo debía evolucionar HTTP. Se publicó como Experimental; la nota aclaró que esto no demostraba por sí solo defectos técnicos y que el texto no debía tratarse como plano universal.

En 2021, el IETF movió RFC 2774 a Historic junto con otros experimentos HTTP. El expediente afirma que los experimentos habían terminado y que no existía evidencia de uso generalizado. IANA registra ahora 510 como Not Extended (OBSOLETED) y marca Man, Opt, C-Man, C-Opt, Ext y C-Ext como obsoleted.

La documentación no autoriza una historia más tajante. No mide despliegues, no prueba que nadie lo utilizara y no identifica una causa única del resultado. Sí establece que el mecanismo dejó de formar parte del repertorio HTTP vigente.

La evolución continuó por otros puntos

HTTP no dejó de extenderse. RFC 9110 enumera puntos persistentes para métodos, códigos de estado, nombres de campo, esquemas de autenticación y directivas de caché. Esos espacios se gobiernan mediante registros y políticas de revisión explícitas, no mediante la matriz genérica de RFC 2774.

El legado útil es una disciplina. Toda novedad debe decir si es opcional o indispensable, quién debe interpretarla, cómo evita colisiones, qué ocurre al atravesar intermediarios y qué evidencia demuestra su ejecución. Un intercambio de bytes exitoso no basta para probar una operación compartida.

510 desapareció como herramienta actual, pero conservó una pregunta incómoda: ¿cómo sabe un cliente que el otro extremo hizo lo que entendía por “éxito”? Cuando no hay una respuesta verificable, la compatibilidad puede ser solo un malentendido bien presentado.

Fuentes