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

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?

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.

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".

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.

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.