Resumo

  • A RFC 1866 ofereceu a quem escrevia HTML uma forma comum de reunir pares nome-valor e enviá-los a um serviço por meio de uma ação e um método declarados.
  • O navegador podia montar a requisição, mas HTML não decidia a resposta do serviço nem comprovava que o efeito pedido havia ocorrido.

A página deixou de ser apenas um destino

Um link oferece caminho para outro recurso. Um formulário permite alterar valores e pedir a um serviço remoto que os processe. O HTML 2.0, publicado como RFC 1866 em novembro de 1995, definiu o formulário como modelo de dados ligado a método e URI de ação. Os dados eram pares nome-valor: o navegador reunia entradas e escolhas, a ação indicava destino e o método definia o envio.

Na época, isso foi um passo da leitura de documentos ao uso de serviços no mesmo navegador. Busca, questionário, cadastro ou reserva cabiam numa página sem cliente específico por site. O padrão descrevia uma troca comum entre navegador e serviço, não a lógica interna deste.

Em 11 de julho de 1994, Paul Burchard enviou a Daniel Connolly uma revisão de FORM com URL de ação, método, codificação e pares nome-valor; HTTP seria o protocolo exigido. GET era padrão; POST serviria a muitos usos. Dez dias depois, Connolly informou que HTML 2.0 estava em revisão final e apontou um validador interativo: a pessoa inseria HTML e recebia a análise conforme a DTD proposta. É um exemplo durante a revisão, não medida de frequência. Atas do IETF em julho também incluem formulários na discussão de padronização.

A RFC 1866 formalizou funções já usadas informalmente e recomendou que agentes de nível 2 oferecessem entrada e envio. Isso é expectativa de conformidade, não prova de implementação em todos os navegadores nem de portabilidade das aplicações. O padrão alinhou a troca no navegador e a construção da requisição.

Com GET, o navegador codificava os dados na URI de ação e a seguia como link. A RFC recomendava GET para processamento idempotente: repetir a requisição não deveria deixar mudança duradoura observável. Busca era o exemplo; a URI podia ser salva ou compartilhada. O documento alertava para URIs longas que servidores antigos tratavam mal e dizia que GET não devia produzir efeitos duradouros.

Para alterar banco ou inscrever alguém, recomendava-se POST. Os pares iam no corpo e o navegador mostrava a resposta. Nenhum método decidia pelo servidor. GET dependia do serviço; POST não garantia transação, recibo ou resultado. Validação e efeito continuavam sob controle do servidor.

O modelo básico não enviava arquivo local como campo comum. A RFC 1867 propôs no mesmo mês INPUT TYPE=FILE, ACCEPT e multipart/form-data para uploads. Era Experimental, não padrão da Internet. Cada recurso tinha status e implementação próprios.

Formulários não criaram sozinhos as aplicações Web. HTTP já tinha métodos, servidores processavam requisições e navegadores variavam. A mudança foi dar aos autores um modo declarativo de incluir valores numa requisição e uma regra comum para montá-la. A pergunta da página, o envio do navegador e a decisão do serviço permaneceram distintos.

Sources