Wie wurden HTML-Formulare Anfang der 90er Jahre interpretiert?

109

Im modernen Web wird ein HTML- <form>Element übermittelt und dann durch Skripten interpretiert. Entweder wird es von einer serverseitigen Programmiersprache (normalerweise PHP) oder von einem clientseitigen Skript (fast immer JavaScript) interpretiert.

Formen gab es schon in den frühen 90er Jahren. Wie wurden sie damals interpretiert?

Laut diesem Wikipedia-Artikel gab es damals eine E-Mail-basierte Übermittlung von HTML-Formularen, die jedoch unzuverlässig war. War das alles was es gab? Warum hatte HTML überhaupt Formulare, wenn sie ohne Skripterstellung so nutzlos waren? Oder war es eine Henne-Ei-Situation?

html forms

— James Jones
quelle

25

Ich benutzte Perl mit

67

Es gab immer serverseitiges Scripting

— OrangeDog

22

Um das Bild zu vervollständigen, wurden einige frühe Formulare verwendet, action="mailto:staff@example.com"die einen Webbrowser anwiesen, einen E-Mail-Client zu starten und die übermittelten Felder als Rohinhalt einer neuen E-Mail zu übertragen. Keine Programmierung, nur einige Mitarbeiter, die die E-Mails von Hand bearbeiten.

— Kubanczyk

2

Vor Formularen gab es sogar solche <ISINDEX> , die oft an einen WAIS- Server angeschlossen waren.

— zwol

182

Vor dem serverseitigen Scripting (PHP, Ruby, node.js) gab es serverseitige Programmierung.

Eine der ursprünglichen Schnittstellen zwischen Webservern und Back-End-Prozessen war das Common Gateway Interface (CGI). Es wurde in den frühen 90er Jahren vom NCSA-Backend-Team eingeführt, während Formulare von Tim Berners-Lee (der zu dieser Zeit auch bei NCSA war) in HTML eingeführt wurden. So wurden Formen ungefähr zur gleichen Zeit eingeführt, als CGI erfunden wurde.

Anfangs haben viele Leute CGI-Programme in C geschrieben. Ich war einer von denen, die dies als Hausaufgabe tun mussten. Anstelle eines riesigen allumfassenden Frameworks haben wir kleine C-Programme geschrieben, die von stdin lesen und in stdout drucken (wir haben die HTTP-Antwort gedruckt, nicht nur den HTML-Code gemäß CGI-Spezifikation). Eine Website hatte viele dieser kleinen Programme, die jeweils eine kleine Sache erledigten und eine Datenbank aktualisierten (manchmal war diese Datenbank nur eine flache Datei).

Fast sobald es eingeführt wurde, fingen die Leute auch an, CGI-Skripte in Perl zu schreiben. Es gab also wirklich keine Übergangszeit zwischen C-Programmen und Skriptsprachen. Die Leute haben einfach aufgehört, CGI-Skripte in C zu schreiben, weil dies in Skriptsprachen schneller war.

— Slebetman
quelle

4

Tolle Antwort von Ihnen und @Dekel. Diese Antworten und die vorgeschlagenen Links füllen die Lücke wirklich. Ich kann nicht anders, als mich zu fragen, wie viele Websites sich tatsächlich die Mühe gemacht haben, diese Dinge zu implementieren, bevor Techniker wie JS, Perl, PHP für Web-Scripting verfügbar waren. Aber das ist eine Frage für einen anderen Tag.

— James Jones

15

@ JamesJones, viele, viele von uns haben es getan. Der Einstieg war nicht allzu schwierig, obwohl die Tools zur Skalierung auf große und leistungsstarke Web-Apps fehlten. Ich habe Ende der 90er Jahre CGI-Programmierung im World Wide Web gelesen und als Teenager angefangen, alle Arten von CGI-Code zu schreiben.

— Dan Lenski

12

Eigentlich ist ein einfaches CGI-Programm sehr einfach zu schreiben. Drucken Sie einfach einige statische Header und HTML mit Ihren Daten aus. Es ist nur so, dass die Technologie (HTML gemischt mit Headern gemischt mit Code ...) nicht gut auf komplexe Anwendungen skaliert werden kann. Daher wurden Frameworks erfunden ...

— Sleske

12

Wenn Sie CGI weiterhin in Aktion sehen möchten, probieren Sie den Fahrplan der Schweizer Eisenbahn aus: sbb.ch - Geben Sie einen Abfahrts- und Zielort ein - drücken Sie die rote Taste - und sehen Sie sich dann die URL im Browser an, insbesondere den Teil query.exe: -)

— theDmi

8

In Bezug auf "wie weit verbreitet war es": Nun, damals waren weit mehr Websites völlig statisch. Die beiden häufig gesehenen aktiven Inhalte waren jedoch "Gästebücher" (veraltet durch Blogs / soziale Medien / Spam) und "Trefferzähler".

— pjc50

70

Die Serverseite war eigentlich immer im Bild.

Der Apache HTTP Server war seit 1995 verfügbar und hatte 1996 auch Perl-Unterstützung (die als serverseitige Programmiersprache verwendet wurde).

JavaScript wurde 1996 erstellt und Netscape war der erste Browser, der die clientseitige Sprache unterstützte (die Implementierungen anderer Browser-Anbieter basierten auf der Arbeit, die in Netscape ausgeführt wurde).

1993 wird der Mosaic-Browser mit Unterstützung für Bilder, verschachtelte Listen und Ausfüllformulare veröffentlicht.

Grundsätzlich ist jeder HTTP-Server, der Anforderungen verarbeiten und an eine Anwendung übergeben kann (unabhängig davon, in welcher Sprache diese Anwendung geschrieben ist), eine serverseitige Anwendung. Es kann in Skriptsprache (Perl / Python / PHP / Ruby), Hochsprache (Java / C #) und, wenn Sie wirklich wollen, sogar in Assembler geschrieben werden. Alles was Sie tun müssen, ist sicherzustellen, dass Sie "dem Protokoll folgen".

— Dekel
quelle

1

Gute Geschichte. Upvoted. Formulare wurden jedoch vor 1995 implementiert. Ich kann nicht genau herausfinden, wann, aber in en.wikipedia.org/wiki/HTML gibt es

Dave Raggett's competing Internet-Draft, "HTML+ (Hypertext Markup Format)", from late 1993, suggested standardizing already-implemented features like tables and fill-out forms.

Ihren letzten Absatz, der Praktiken vor 1995 beschreibt?

— James Jones

3

@ JamesJones: Überprüfen Sie Wikipedia-Eintrag auf Common Gateway Interface

— Slebetman

2

@JamesJones, einige Informationen zum Mosaik-Browser und zum Ausfüllen von Formularen hinzugefügt. Sie haben auch eine gute Antwort von Slebetman in Bezug auf CGI.

— Dekel

1

@ JamesJones-Standards sind nicht eindeutig und gelten in vollem Umfang für die meisten Dinge im Internet (wenn auch nicht für das gesamte Internet). Der HTML-Standard war (und ist es immer noch) schrecklich und jeder hat seine eigenen Erweiterungen erstellt. Mosaic, Netscape und Internet Explorer waren die bekanntesten - die meisten ihrer Erweiterungen wurden späteren HTML-Standards hinzugefügt, wobei Netscape und IE ziemlich viel zusammenarbeiten. HTML hatte damals noch nicht einmal eingebettete Bilder ( img) - der Autor hielt es für nicht passend für die Idee von Hypertext; nur der Erfolg von Mosaic / Netscape erzwang die Änderung des Standards.

— Luaan

3

Diese Antwort ist nicht unbedingt falsch, aber ich bin mir nicht ganz sicher, wie die Dinge, die mindestens 2-3 Jahre nach der Verfügbarkeit von Formularen im Browser eingeführt wurden, ein Beweis dafür sind, dass Formulare immer serverseitig unterstützt wurden.

— 8bittree

1

JavaScript war nicht so weit fortgeschritten (Hölle Ajax war noch nicht einmal raus). Es war also rein serverseitig. Meistens CGI (Perl) und PHP.

Es gab auch Coldfusion, war aber kein beliebter Favorit.

Ende 1999 und Anfang der 2000er Jahre kamen schließlich ASP.NET (aspx) und JavaServer Pages (jsp) heraus, obwohl viele kommerzielle Websites aus offensichtlichen Gründen aspx und jsp verwendeten.

Beachten Sie, dass auch Java-Applets vorhanden waren (hauptsächlich zum Rendern), die jedoch separat heruntergeladen und vom Browser unterstützt werden mussten.

— tfont
quelle

3

Eigentlich habe ich ASPs Anfang 1998 programmiert. Davor gab es einen anderen MS-Standard namens htxTemplates.

— Little Santi

1

^ klingt wie du eines der Originale warst! Vor langer Zeit Kumpel! : D: D

— tfont

1

Außerdem bin ich auf ein interessantes Stück Geschichte auf Wikipedia gestoßen. HTML-Formulare können auch per E-Mail unter Verwendung einer mailto:Adresse im targetAttribut gesendet werden . Schien nicht beliebt zu sein, aber trotzdem cool!

Zitieren des Wikipedia-Artikels :

Die Unterstützung von Benutzeragenten für die E-Mail-basierte Übermittlung von HTML-Formularen unter Verwendung einer Mailto-URL als Formularaktion wurde in Abschnitt 5.6 von RFC 1867 während der HTML 3.2-Ära vorgeschlagen. Verschiedene Webbrowser haben es implementiert, indem sie ein separates E-Mail-Programm aufgerufen oder ihre eigenen rudimentären SMTP-Funktionen verwendet haben. Obwohl manchmal unzuverlässig, war es kurzzeitig eine einfache Möglichkeit, Formulardaten ohne Webserver oder CGI-Skripte zu übertragen.

Und RFC 1867 (November 1995):

5.6 Lassen Sie das Formular ACTION "mailto:"

Unabhängig von diesem Vorschlag wäre es für HTML-
interpretierende Benutzeragenten sehr nützlich , eine AKTION in einem Formular als
"mailto:" - URL zuzulassen . Dies scheint eine gute Idee zu sein, mit oder ohne diesen
Vorschlag. Ebenso sollte die AKTION für ein HTML-Formular, das per E-Mail empfangen wird, wahrscheinlich standardmäßig "Antwort auf:" der Nachricht sein.
Mit diesen beiden Vorschlägen könnten HTML-Formulare über HTTP-
Server bereitgestellt, aber per E-Mail zurückgesendet werden, oder alternativ könnten HTML-Formulare
per E-Mail gesendet, von HTML-fähigen E-Mail-Empfängern ausgefüllt und die Ergebnisse zurückgesendet werden.

— Baptiste Candellier
quelle