Résumé

  • La RFC 1866 a donné aux auteurs HTML une manière commune de recueillir des paires nom-valeur et de les envoyer à un service selon une action et une méthode déclarées.
  • Le navigateur pouvait construire une requête, mais HTML ne déterminait ni la décision du service ni la preuve qu’un effet demandé avait eu lieu.

La page n’était plus seulement une destination

Un lien donne au lecteur un chemin vers une autre ressource. Un formulaire permet de modifier les valeurs d’un document et de demander leur traitement à un service distant. HTML 2.0, publié comme RFC 1866 en novembre 1995, définit le formulaire comme un modèle de jeu de données associé à une méthode et à une URI d’action. Les données sont des paires nom-valeur : le navigateur recueille les saisies et choix, l’action indique la destination, et la méthode détermine l’envoi.

Cette définition paraît banale aujourd’hui. Elle marquait alors un pas de la lecture de documents vers l’usage de services réseau dans le même navigateur. Recherche, questionnaire, inscription ou réservation pouvaient tenir dans une page sans client spécialisé par site. La norme décrivait une enveloppe commune entre navigateur et service, pas tous les traitements de celui-ci.

Les archives montrent le modèle en formation en 1994. Le 11 juillet, Paul Burchard envoya à Daniel Connolly une révision de FORM : URL d’action, méthode, encodage et paires nom-valeur. HTTP était le protocole dont la prise en charge serait exigée. GET était la méthode par défaut ; POST devait convenir à de nombreux usages. Dix jours après, Connolly annonçait la revue finale de HTML 2.0 et un validateur interactif : l’utilisateur saisissait du HTML et recevait l’analyse du serveur selon la DTD proposée. C’est un exemple pendant la revue, non une mesure de fréquence.

Les minutes de l’IETF mentionnent aussi les formulaires parmi les sujets techniques de normalisation.

La RFC 1866 formalisa des fonctions déjà utilisées de manière informelle et recommanda aux agents de niveau 2 la saisie et l’envoi. Cela exprime une attente, pas la preuve que chaque navigateur gérait chaque contrôle, ni que les applications derrière les formulaires étaient portables. Le texte normalisait l’échange côté navigateur et la construction de la requête.

Avec GET, le navigateur encodait les valeurs dans l’URI d’action et la suivait comme un lien. La RFC recommandait GET pour un traitement idempotent, sans changement durable observable en cas de répétition ; la recherche en était l’exemple. L’URI pouvait être enregistrée ou partagée. Le document avertissait que les URI longues posaient problème à certains serveurs et qu’un GET ne devait pas déclencher d’effet durable.

Pour modifier une base de données ou inscrire quelqu’un, POST était recommandé. Il plaçait les paires encodées dans le corps de la requête et le navigateur affichait la réponse. Aucune méthode ne décidait du comportement serveur. GET dépendait du service pour rester sans effet ; POST ne garantissait ni transaction, ni reçu, ni résultat. Validation et effet restaient sous le contrôle du serveur.

Le modèle initial ne pouvait pas envoyer un fichier local comme champ ordinaire. RFC 1867 proposa le même mois INPUT TYPE=FILE, ACCEPT et multipart/form-data. Elle était expérimentale, non une norme Internet. Chaque extension suivait son statut et son chemin d’implémentation.

Les formulaires n’ont pas créé seuls les applications Web. HTTP avait déjà des méthodes, les serveurs traitaient des requêtes, les navigateurs variaient. Le changement circonscrit était d’offrir une manière déclarative d’insérer des valeurs utilisateur dans une requête et une règle commune pour la construire. La demande de la page, l’envoi du navigateur et la décision du service restaient distincts.

Sources