Comment les formulaires HTML étaient-ils interprétés au début des années 90?

109

Dans le Web moderne, un <form>élément HTML est soumis puis interprété par script. Soit il est interprété par un langage de programmation côté serveur (généralement PHP), soit il est interprété par un script côté client (presque toujours JavaScript).

Les formulaires existaient même au début des années 90. Comment étaient-ils interprétés à l'époque?

Selon cet article de Wikipedia, il y avait à l'époque une soumission de formulaire HTML par courrier électronique, mais elle n'était pas fiable. C'était tout ce qu'il y avait? Pourquoi le HTML avait-il même des formulaires s'ils étaient si inutiles sans script? Ou était-ce une sorte de situation de poulet et d'oeuf?

html forms

— James Jones
source

25

J'ai utilisé perl avec cgi

67

Il y avait toujours des scripts côté serveur

— OrangeDog

22

Pour compléter le tableau, certains formulaires précoces ont été utilisés pour action="mailto:staff@example.com"indiquer à un navigateur Web de démarrer un client de messagerie et de transférer les champs soumis en tant que contenu brut d'un nouvel e-mail. Zéro programmation, juste du personnel pour traiter les e-mails à la main.

— kubanczyk

2

Avant les formulaires, même, il y en avait <ISINDEX>, qui était souvent branché sur un serveur WAIS .

— zwol

182

Avant les scripts côté serveur (PHP, Ruby, node.js), il y avait une programmation côté serveur.

L'une des interfaces d'origine entre les serveurs Web et les processus back-end était la Common Gateway Interface (CGI). Il a été introduit au début des années 90 par l'équipe back-end du NCSA au moment où les formulaires ont été introduits dans HTML par Tim Berners-Lee (qui était également à NCSA à l'époque). Ainsi, les formulaires ont été introduits à peu près au même moment où CGI a été inventé.

Au départ, beaucoup de gens ont écrit des programmes CGI en C. J'étais l'un de ceux qui devaient le faire comme devoir à la maison. Au lieu d'un cadre gigantesque, nous avons écrit de petits programmes C qui lisent depuis stdin et impriment vers stdout (nous avons imprimé la réponse HTTP, pas seulement le HTML selon les spécifications CGI). Un site Web avait beaucoup de ces petits programmes, chacun faisant une petite chose et mis à jour une base de données (parfois cette base de données n'était qu'un fichier plat).

Presque dès son introduction, les gens ont également commencé à écrire des scripts CGI en Perl. Il n'y avait donc pas vraiment de période de transition entre les programmes C et les langages de script. Les gens ont tout simplement arrêté d'écrire des scripts CGI en C parce que c'était plus rapide de le faire dans les langages de script.

— dormeur
source

4

Excellente réponse de vous et de @Dekel. Ces réponses et les liens suggérés comblent vraiment le vide. Je ne peux pas m'empêcher de me demander combien de sites Web ont réellement pris la peine de mettre en œuvre l'un de ces éléments avant que des technologies comme JS, Perl et PHP soient disponibles pour les scripts Web. Mais c'est une question pour un autre jour.

— James Jones

15

@JamesJones, beaucoup d'entre nous l'ont fait. Ce n'était pas si difficile de démarrer, même si les outils pour évoluer vers de grandes applications Web très performantes faisaient défaut. J'ai lu la programmation CGI sur le World Wide Web à la fin des années 90 et j'ai commencé à écrire toutes sortes de codes CGI à l'adolescence.

— Dan Lenski

12

En fait, un programme CGI de base est très facile à écrire. Imprimez simplement des en-têtes statiques et du HTML avec vos données entrecoupées. C'est juste que la technologie (HTML mélangé avec des en-têtes mélangés avec du code ...) ne s'adapte pas bien aux applications complexes. C'est pourquoi les frameworks ont été inventés ...

— sleske

12

Si vous voulez toujours voir CGI en action, essayez l'horaire des chemins de fer suisses: sbb.ch - entrez un lieu de départ et de destination - appuyez sur le bouton rouge - puis jetez un œil à l'URL dans le navigateur, en particulier la partie query.exe: -)

— theDmi

8

En ce qui concerne «à quel point c'était répandu»: eh bien, beaucoup plus de sites Web étaient complètement statiques à l'époque. Mais les deux éléments de contenu actif les plus courants étaient les «livres d'or» (obsolètes par les blogs / médias sociaux / spam) et les «compteurs de résultats».

— pjc50

70

Le côté serveur était en fait toujours dans l'image.

Le serveur HTTP Apache était disponible depuis 1995 et, en 1996, il supportait également Perl (qui était utilisé comme langage de programmation côté serveur).

JavaScript a été créé en 1996 et Netscape a été le premier navigateur à prendre en charge le langage côté client (les implémentations d'autres fournisseurs de navigateurs étaient basées sur le travail effectué dans Netscape).

En 1993, le navigateur Mosaic est lancé avec la prise en charge des images, des listes imbriquées et des formulaires à remplir.

Fondamentalement, chaque serveur HTTP qui pourrait gérer la demande et la transmettre à une application (quelle que soit la langue dans laquelle cette application est écrite) est une application côté serveur. Il peut être écrit en langage de script (Perl / Python / PHP / Ruby), en langage de haut niveau (Java / C #) et si vous le souhaitez vraiment - même en assemblage. Tout ce que vous avez à faire est de vous assurer de "suivre le protocole".

— Dekel
source

1

Bonne histoire. J'ai voté pour. Cependant, les formulaires ont été implémentés avant 1995. Je ne peux pas déterminer quand, mais dans en.wikipedia.org/wiki/HTML il y a

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

Votre dernier paragraphe décrivant les pratiques avant 1995?

— James Jones

3

@JamesJones: Vérifiez l'entrée de wikipedia sur Common Gateway Interface

— slebetman

2

@JamesJones, a ajouté quelques informations concernant le navigateur Mosaic et les formulaires à remplir. Vous avez également une excellente réponse de slebetman concernant CGI.

— Dekel

1

Les standards @JamesJones ne sont pas clairs et s'appliquent intégralement à la plupart des choses sur le Web (mais pas à Internet dans son ensemble). Le standard HTML était (et l'est toujours) horrible, et chacun a créé ses propres extensions. Mosaic, Netscape et Internet Explorer étaient les plus notoires - la plupart de leurs extensions ont été ajoutées aux normes HTML ultérieures, Netscape et IE coopérant un peu à ce sujet. Le HTML n'avait même pas d'images intégrées ( img) à l'époque - l'auteur le considérait comme inadapté à l'idée d'hyper-texte; seul le succès de Mosaic / Netscape a forcé le changement de norme.

— Luaan

3

Cette réponse n'est pas nécessairement fausse, mais je ne sais pas trop comment les choses introduites au moins 2-3 ans après la disponibilité des formulaires dans le navigateur sont la preuve qu'il y a toujours eu un support côté serveur pour les formulaires.

— 8bittree

1

JavaScript n'était pas si avancé (l'enfer Ajax n'était même pas encore sorti). C'était donc purement côté serveur. Principalement CGI (étant Perl) et PHP.

Il y avait aussi Coldfusion mais n'était pas un favori populaire.

Finalement, à la fin de 1999 et au début des années 2000, ASP.NET (aspx) et JavaServer Pages (jsp) sont sortis, bien que de nombreux sites commerciaux aient utilisé aspx et jsp pour des raisons évidentes.

Notez que les applets Java existaient également (surtout pour le rendu) mais devaient être téléchargées séparément et prises en charge par le navigateur.

— tfont
source

3

En fait, j'ai programmé des ASP au début de 1998. Avant cela, il y avait un autre standard MS appelé htxtemplates.

— Little Santi

1

^ on dirait que vous étiez l'un des originaux! Il y a longtemps mec! : D: D

— tfont

1

De plus, je suis tombé sur un morceau d'histoire intéressant sur Wikipedia. Les formulaires HTML peuvent également être envoyés par e-mail, en utilisant une mailto:adresse dans l' targetattribut. Cela ne semblait pas être populaire, mais toujours cool!

Citant l'article de Wikipédia :

La prise en charge de l'agent utilisateur pour la soumission de formulaires HTML par courrier électronique, en utilisant une URL «mailto» comme action de formulaire, a été proposée dans la section 5.6 de la RFC 1867, à l'époque HTML 3.2. Divers navigateurs Web l'ont implémenté en invoquant un programme de messagerie séparé ou en utilisant leurs propres capacités SMTP rudimentaires. Bien que parfois peu fiable, il était brièvement populaire comme moyen simple de transmettre des données de formulaire sans impliquer un serveur Web ou des scripts CGI.

Et RFC 1867 (novembre 1995):

5.6 Autoriser le formulaire ACTION à être "mailto:"

Indépendamment de cette proposition, il serait très utile pour
les agents utilisateurs d'interprétation HTML de permettre à une ACTION dans un formulaire d'être une
URL "mailto:". Cela semble être une bonne idée, avec ou sans cette
proposition. De même, l'ACTION pour un formulaire HTML qui est reçu par courrier électronique devrait probablement être par défaut la "réponse:" du message.
Ces deux propositions permettraient aux formulaires HTML d'être servis via des
serveurs HTTP mais renvoyés par courrier, ou, alternativement, permettraient aux formulaires HTML
d'être envoyés par courrier, remplis par des destinataires de courrier HTML et les résultats renvoyés par courrier.

— Baptiste Candellier
source