Summary

  • A descrição do HTTP implementado para a Web de 1991 mostra um pedido único GET seguido por um documento HTML; o servidor indicava o fim ao fechar a conexão.
  • Esse intercâmbio não tinha linha de status nem cabeçalhos. As notas de projeto dizem que um erro voltava como documento e só podia ser distinguido do sucesso pela leitura do texto.
  • O HTTP ganhou versão, cabeçalhos e códigos de status, mas manteve a forma simples para compatibilidade; essa continuidade não mede quanto o HTTP/0.9 foi usado.

A página era toda a resposta

Na implementação da World Wide Web descrita em 1991, o cliente abria uma conexão com o servidor. Se o endereço não especificasse uma porta, usava a 80. Em seguida, enviava uma linha GET com o identificador do documento. O servidor respondia com um fluxo de bytes em HTML e fechava a conexão depois de transmitir o documento. Não havia uma linha de status antes da página nem um bloco de cabeçalhos depois dela: os primeiros bytes recebidos já faziam parte do documento.

O registro de Tim Berners-Lee não descreve um envelope HTTP invisível envolvendo cada página. Ele chama a resposta de mensagem HTML e diz que o fechamento da conexão a encerra. O servidor também podia enviar texto de erro legível em HTML. A limitação aparece de forma explícita: não havia como distinguir uma resposta de erro de uma satisfatória sem ler o próprio texto. O navegador conseguia exibir o conteúdo, mas o formato não fornecia um código legível por máquina para indicar página inexistente, redirecionamento ou erro do servidor.

O resumo de junho de 1992 expõe a troca. O navegador enviava um único comando, GET, seguido do identificador de um documento, que podia incluir palavras-chave para consultar um índice nomeado. O servidor não mantinha estado sobre o navegador. A resposta podia ser HTML ou texto simples e conter um documento, um menu ou uma lista de resultados. A simplicidade era uma vantagem: do servidor saía apenas texto marcado. Mas o resumo também aponta a falta de uma fronteira lexical entre informações HTTP, conteúdo e tipo do documento. Uma mensagem de erro continuava sendo um documento, que o leitor podia ignorar.

Essa ambiguidade pertence ao formato da mensagem; não prova que servidores antigos falhavam com frequência nem que pessoas não entendiam uma página de erro. Uma pessoa podia ler o corpo. Um programa não tinha um campo de status para consultar. Além disso, o fechamento da conexão marcava tanto o fim normal do documento quanto o encerramento de uma troca interrompida. O cliente sabia que o fluxo tinha parado, mas não por quê.

O projeto inicial tampouco se limitava a páginas estáticas. Um elemento ISINDEX podia levar o navegador a montar uma consulta anexando palavras-chave ao identificador do documento; o servidor podia devolver uma lista HTML de resultados. No texto sobre a necessidade de um novo protocolo, Berners-Lee também cita pesquisa em índices, negociação automática de formato e encaminhamento para outro servidor como capacidades desejáveis de acesso à informação. São objetivos do projeto mais amplo, não prova de que a troca simples já oferecia todos eles.

Uma resposta mais rica sem apagar a antiga

Uma mensagem pública de dezembro de 1992 na lista www-talk registra uma proposta de ampliação. Berners-Lee propôs que servidores novos continuassem reconhecendo GET <url>, enquanto clientes poderiam incluir um identificador de versão na mesma linha e depois cabeçalhos como From, Accept e Accept-Encoding. O exemplo de resposta traz uma versão, um campo de resposta, tipo de conteúdo MIME e os métodos permitidos. Era uma proposta em discussão, não uma captura definitiva do formato implantado. Ainda assim, mostra que a resposta precisava descrever a si própria, além de entregar o conteúdo.

O RFC 1945, publicado como RFC Informational em 1996, descreveu depois as duas formas. O pedido simples continuava sendo GET mais um URI, sem cabeçalhos; a resposta simples continuava sendo apenas o corpo e terminava quando o servidor fechava a conexão. A resposta completa começava com uma linha de status e podia trazer cabeçalhos de resposta e da entidade. O RFC alerta que o pedido simples impedia o servidor de identificar o tipo de mídia devolvido. Preservar o reconhecimento da forma antiga permitia aos sistemas posteriores considerar clientes e servidores anteriores sem fingir que trocavam a mesma mensagem.

A cronologia importa: a definição retrospectiva do RFC ajuda a entender a compatibilidade, mas não prova que um padrão HTTP/0.9 separado tenha sido ratificado em 1991. Berners-Lee recordou depois que o primeiro servidor e os primeiros clientes da Web, incluindo o navegador em modo de linha de Nicola Pellow, chegaram à comunidade de física de altas energias e, depois, às comunidades de hipertexto e NeXT no verão de 1991. Ele também disse que as especificações de URI, HTML e HTTP foram publicadas no primeiro servidor para incentivar discussão e adoção.

Essas fontes dão contexto à experiência, mas não contam quantas instalações usaram cada forma.

Uma resposta que era o próprio documento tornava o sistema fácil de entender: pedir um recurso e receber conteúdo que o navegador podia mostrar. A limitação surgia quando o cliente precisava tratar a resposta como um evento do protocolo. Sem linha de status, página e erro ocupavam o mesmo lugar. As mensagens completas do HTTP separaram resultado, metadados e representação; a forma simples permaneceu reconhecível por compatibilidade.

Fontes