Zusammenfassung

  • RFC 1866 gab HTML-Autoren ein gemeinsames Verfahren, Name-Wert-Eingaben über eine angegebene Aktion und Methode an einen Dienst zu senden.
  • Der Browser konnte eine Anfrage aufbauen; HTML bestimmte jedoch weder die Entscheidung des Dienstes noch den Nachweis, dass die gewünschte Wirkung eingetreten war.

Die Seite wurde mehr als ein Ziel

Ein Link weist zu einer anderen Ressource. Ein Formular ermöglicht, Werte zu ändern und einen entfernten Dienst um Verarbeitung zu bitten. HTML 2.0, im November 1995 als RFC 1866 veröffentlicht, definierte ein Formular als Datensatzvorlage mit Methode und Aktions-URI. Der Datensatz bestand aus Name-Wert-Paaren: Der Browser sammelte Eingaben, die Aktion nannte das Ziel, die Methode bestimmte die Übertragung.

Damals war das ein Schritt vom Dokumentenlesen zur Nutzung vernetzter Dienste im selben Browser. Suche, Fragebogen, Anmeldung oder Reservierung konnten ohne eigenen Client pro Website auf einer Seite stehen. Der Standard beschrieb eine gemeinsame Hülle zwischen Browser und Dienst, nicht dessen gesamte Logik.

Am 11. Juli 1994 schickte Paul Burchard Daniel Connolly eine überarbeitete FORM-Spezifikation mit Aktions-URL, Methode, Kodierung und Name-Wert-Paaren. HTTP sollte das erforderliche Zugriffsprotokoll sein. GET war Standard, POST für viele Anwendungen vorgesehen. Zehn Tage später meldete Connolly die Schlussprüfung von HTML 2.0 und verwies auf einen interaktiven Validator: Nutzer gaben HTML ein und erhielten das Prüfergebnis anhand der vorgeschlagenen DTD. Das ist ein konkreter Fall, keine Verbreitungsstatistik. IETF-Protokolle im Juli führen Formulare als Standardthema.

RFC 1866 formalisierte bereits informell genutzte Funktionen und empfahl Level-2-User-Agents Formulareingabe und -übermittlung. Das setzt eine Erwartung, beweist aber weder die Umsetzung jedes Elements in jedem Browser noch portables Verhalten dahinter. Standardisiert wurden Browseraustausch und Anfrageaufbau.

Bei GET kodierte der Browser Daten in die Aktions-URI und rief sie wie einen Link auf. Die RFC empfahl GET für idempotente Verarbeitung, bei der eine Wiederholung keine dauerhafte Änderung hinterlässt. Suche war das Beispiel; die URI ließ sich speichern oder teilen. Die RFC warnte vor langen URIs und Nebenwirkungen von GET. Wenn eine Übermittlung eine Datenbank änderte oder jemanden anmeldete, empfahl sich POST. Es legte die Paare in den Anfragekörper und der Browser zeigte die Antwort.

Keine Methode bestimmte die Serverhandlung. GET blieb nur dann folgenlos, wenn der Dienst es so behandelte; POST garantierte weder Transaktion noch Beleg oder Ergebnis. Prüfung und Wirkung blieben beim Server. Die Grundform konnte keine lokale Datei als gewöhnliches Feld senden. RFC 1867 schlug im selben Monat INPUT TYPE=FILE, ACCEPT und multipart/form-data vor. Sie war ausdrücklich Experimental, kein Internetstandard.

Formulare schufen Webanwendungen nicht allein. Die begrenzte Veränderung war eine deklarative HTML-Möglichkeit, Nutzerwerte in Anfragen aufzunehmen, plus eine gemeinsame Regel zum Aufbau. Seitenfrage, Browserübermittlung und Dienstentscheidung blieben getrennt.

Sources