Summary

  • La descripción de HTTP implementado para la Web de 1991 muestra una solicitud GET seguida de un documento HTML, cuyo final señalaba el servidor al cerrar la conexión.
  • El intercambio no tenía línea de estado ni cabeceras. Las notas de diseño indican que un error volvía como documento y solo se distinguía del éxito por su texto.
  • HTTP añadió después versión, cabeceras y códigos de estado, pero conservó el intercambio simple por compatibilidad; esa continuidad no mide cuánto se utilizó HTTP/0.9.

La página era toda la respuesta

En la implementación del World Wide Web descrita en 1991, el cliente abría una conexión con el servidor y usaba el puerto 80 si la dirección no indicaba otro. Después enviaba una línea GET con el identificador del documento. El servidor respondía con un flujo de texto HTML y cerraba la conexión cuando terminaba de transmitirlo. No había una línea de estado delante de la página ni un bloque de cabeceras detrás: los primeros bytes recibidos ya pertenecían al documento.

El archivo de Tim Berners-Lee no describe un envoltorio HTTP invisible que rodeara cada página. Dice que la respuesta era un mensaje HTML y que el cierre de conexión la terminaba. También señala que los errores podían llegar como texto legible en HTML y reconoce el coste: no había manera de distinguir una respuesta de error de una satisfactoria salvo leyendo el texto. El navegador podía mostrar lo recibido, pero el formato no ofrecía un código interpretable por máquinas para indicar documento ausente, redirección o error del servidor.

El resumen de junio de 1992 expone el equilibrio. El navegador enviaba un solo comando, GET, seguido de un identificador que podía incluir palabras clave para consultar un índice con nombre. El servidor no guardaba estado respecto al navegador. La respuesta podía ser HTML o texto plano e incluir un documento, un menú o una lista de resultados. La sencillez era una ventaja: del servidor solo salía texto marcado. Sin embargo, el resumen también identifica lo que faltaba: HTTP, el contenido y el tipo del documento no tenían una separación léxica. Un mensaje de error seguía siendo un documento; el lector podía pasarlo por alto.

La ambigüedad estaba en el formato, no demuestra que los primeros servidores fallaran con frecuencia ni que una persona no entendiera una página de error. Una persona podía leerla; un programa no tenía un campo de estado que consultar. Además, el cierre de conexión marcaba tanto el final normal del documento como la terminación de un intercambio interrumpido. Indicaba que el flujo había parado, no por qué.

El diseño inicial tampoco se limitaba a páginas estáticas. Una etiqueta ISINDEX podía indicar al navegador que construyera una consulta al añadir palabras clave al identificador del documento; el servidor podía responder con una lista HTML. En su texto sobre la necesidad de un nuevo protocolo, Berners-Lee también enumera la búsqueda en índices, la negociación automática del formato y la posibilidad de enviar al cliente a otro servidor como capacidades deseables. Son objetivos de diseño, no prueba de que el intercambio simple ya ofreciera todas esas funciones.

Una respuesta más rica, con compatibilidad

En diciembre de 1992, un mensaje de la lista pública www-talk muestra una propuesta para ampliar el protocolo. Berners-Lee plantea que los servidores nuevos sigan reconociendo GET <url>, mientras los clientes pueden añadir un indicador de versión en la misma línea y luego cabeceras como From, Accept y Accept-Encoding. Su ejemplo de respuesta incluye versión, un campo de respuesta, tipo MIME y métodos permitidos. Era una propuesta en discusión, no una captura definitiva del formato que llegó a desplegarse. Sí muestra la necesidad de describir la propia respuesta y no solo entregar su contenido.

El RFC 1945, publicado como RFC Informational en 1996, documentó después ambas formas. La solicitud simple seguía siendo GET más un URI, sin cabeceras; la respuesta simple seguía siendo solo el cuerpo y terminaba cuando el servidor cerraba la conexión. La respuesta completa empezaba con una línea de estado y podía incluir cabeceras de respuesta y de entidad. El RFC advierte que la solicitud simple impedía al servidor identificar el tipo de medio devuelto. Mantener reconocible el formato antiguo permitió a los sistemas posteriores considerar clientes y servidores anteriores sin fingir que intercambiaban el mismo mensaje.

La cronología importa: la definición retrospectiva del RFC ayuda a entender la compatibilidad, pero no demuestra que HTTP/0.9 fuera un estándar separado ratificado en 1991. Berners-Lee recordó que el primer servidor y los primeros clientes de la Web, incluido el navegador de línea de comandos de Nicola Pellow, llegaron a la comunidad de física de altas energías y después a los grupos de hipertexto y NeXT en el verano de 1991. También dijo que las especificaciones de URI, HTML y HTTP se publicaron en el primer servidor para fomentar su adopción y debate. Esas fuentes sitúan el experimento; no cuentan cuántas instalaciones usaron cada formato.

Una respuesta que era el propio documento hacía el sistema sencillo de entender: pedir un recurso y recibir contenido que el navegador pudiera mostrar. El límite aparecía cuando el cliente debía interpretar la respuesta como un evento de protocolo. Sin línea de estado, una página y un error ocupaban el mismo lugar. Los mensajes HTTP más completos separaron resultado, metadatos y representación, mientras el formato simple siguió siendo reconocible.

Fuentes