Resumen

  • RFC 3205 planteó la reutilización de HTTP como una decisión de arquitectura con comportamiento heredado, no como una garantía automática de interoperabilidad o seguridad.
  • Su exigencia práctica era la precisión: documentar la identidad del servicio, los proxies, las cachés y la frontera entre errores HTTP y resultados de la aplicación.

En la negociación había otra parte

A comienzos de 2002, HTTP ofrecía un conjunto tentador para los protocolos de aplicación nuevos. Los desarrolladores ya lo conocían; los navegadores podían usarlo; había servidores y bibliotecas cliente disponibles. A veces también se podían aprovechar TLS y mecanismos de autenticación conocidos. Si una organización ya operaba un servicio web, usar la misma maquinaria parecía abaratar el prototipo. Atravesar cortafuegos también figuraba entre las ventajas citadas.

La BCP 56 de Keith Moore hizo visible a un participante menos obvio: todo el ecosistema HTTP entre las dos aplicaciones. Una solicitud podía pasar por una biblioteca cliente, un proxy, una caché, un cortafuegos, un traductor de direcciones, un servidor web y, finalmente, el código de la aplicación. Cada componente leía campos familiares con un significado genérico. Ahorrar esfuerzo en una pieza no hacía que las demás compartieran el sentido particular de la aplicación.

El documento se define como recomendación, no como una especificación de conformidad; deliberadamente evita las palabras normativas en mayúsculas de RFC 2119. Por eso no propone que todas las aplicaciones abandonen HTTP. Pide evaluar el coste completo. HTTP ya había acumulado conexiones persistentes, rangos de bytes, negociación de contenido y caché; una aplicación superpuesta podía heredar funciones que no necesitaba y gastar esfuerzo en limitarlas. Para transacciones pequeñas y frecuentes, la sobrecarga de TCP y HTTP podía importar. Las conexiones persistentes podían repartir el coste de conexión entre varios intercambios.

Un código familiar podía contar otra historia

El caso difícil aparecía cuando el éxito de HTTP no coincidía con el resultado de la aplicación. Un proxy no tenía que entender el nuevo protocolo para aplicar la semántica ordinaria de HTTP. En ciertas condiciones podía guardar una respuesta exitosa y entregarla ante una solicitud parecida. También podía sustituir o ampliar el cuerpo de una respuesta de error. Así, el cliente podía recibir una respuesta HTTP válida cuyo significado para la aplicación se había vuelto obsoleto, se había ocultado o había cambiado.

RFC 3205 separó los errores de la línea de solicitud y las cabeceras HTTP de los resultados propios de la aplicación. Si el protocolo usaba respuestas genéricas 200 o 500 para resultados del cuerpo, debía especificar cómo evitar una caché perjudicial y cómo funcionar si un intermediario modificaba el cuerpo del error. Si no podía tolerar que un proxy almacenara o alterara esas respuestas, el consejo era no usar HTTP como base. El problema no era que «los códigos HTTP sean malos», sino que dos capas podían definir el éxito de maneras distintas.

Lo mismo ocurría con los métodos y los tipos MIME. El tipo de contenido indica qué clase de objeto se transmite, no qué operación debe ejecutar quien lo recibe. La acción debía expresarse aparte. Definir un método HTTP nuevo tampoco resolvía por sí solo si un servicio distinto necesitaba otro puerto o esquema URI.

Reutilizar también era decidir cómo identificar el servicio

El puerto 80 y el esquema http: ya tenían significado para operadores, software y usuarios. RFC 3205 preguntaba si el nuevo servicio tenía otros datos, código, procesos o necesidades de control del tráfico; esas diferencias podían justificar un puerto propio. Un servicio de uso amplio con configuración, credenciales o aprovisionamiento distintos podía requerir también su propio esquema URI. No era una cuestión cosmética de nombres, sino de identificar el servicio en la operación.

Las bibliotecas traían más supuestos. Un cliente podía convertir la URL de un servicio en una URL con apariencia HTTP para llamar a una biblioteca; un proxy podía ver entonces la URL completa e interpretarla como una solicitud web convencional. Una biblioteca podía transmitir HTTP/1.1 aunque la aplicación aún tuviera que explicar qué significaba esa etiqueta de versión en su intercambio. La especificación, no una expectativa optimista sobre el código reutilizado, debía describir la relación entre cliente, servidor y proxy.

La reutilización desplaza parte del trabajo. El código existente puede acelerar la primera implementación, pero su comportamiento genérico pasa a formar parte de la frontera del sistema. Cuantas más implementaciones independientes haya, más oportunidades existen de que un atajo en el cliente choque con una regla de caché o con lo que espera el servidor. Es una interpretación del análisis de diseño de RFC 3205, no una estimación medida del gasto de ingeniería ni una prueba de que fallara un protocolo concreto.

El sucesor confirma que el problema perduró

En 2022, RFC 9205 sustituyó a RFC 3205 como BCP 56. Tras dos décadas de evolución de HTTP, aborda las API basadas en HTTP que mantienen equipos distintos, la evolución descoordinada de clientes y servidores, la extensibilidad, las cachés, el estado, la autenticación y la convivencia con la navegación web. La revisión muestra que el asunto merecía una guía actualizada. No demuestra que las recomendaciones se adoptaran universalmente ni que el texto de 2002 anticipara todas las prácticas posteriores.

La lección histórica es más acotada: reutilizar un protocolo no elimina sus fronteras; traslada el trabajo a las semánticas del software compartido. Dos implementaciones pueden compilar contra la misma biblioteca HTTP y aun así discrepar sobre el significado de una respuesta. Para interoperar hay que especificar qué pueden hacer los componentes HTTP del entorno, qué debe hacer la aplicación y a qué capa corresponde cada resultado.

El vocabulario arquitectónico para los equipos intermedios aparece en RFC 3234. El contexto HTTP/1.1 de aquella época está en RFC 2616; la convención de palabras normativas que RFC 3205 decidió no emplear está en RFC 2119. Las fuentes oficiales son RFC 3205, su ficha del RFC Editor, la ficha de IETF Datatracker, RFC 9205 y su ficha del RFC Editor.