How were HTML forms interpreted in the early 90s?

HtmlForms

Html Problem Overview


In the modern web an HTML <form> element is submitted and then interpreted by scripting. Either it is interpreted by a server side programming language (usually PHP) or it is interpreted by a client side script (almost always JavaScript).

Forms existed even in the early 90s. How were they interpreted back then?

According to this Wikipedia article there was an email based HTML form submission back then, but it was unreliable. Was this all there was? Why did HTML even have forms if they were so useless without scripting? Or was it a chicken and egg sort of situation?

Html Solutions


Solution 1 - Html

Before server side scripting (PHP, Ruby, node.js) there was server side programming.

One of the original interfaces between web servers and back-end processes was the Common Gateway Interface (CGI). It was introduced in the early 90s by the NCSA back-end team at the same time forms was introduced into HTML by Tim Berners-Lee (who was also at NCSA at the time). So forms was introduced at roughly the same time CGI was invented.

Initially a lot of people wrote CGI programs in C. I was one of those who had to do so as a homework assignment. Instead of a giant all-encompassing framework we wrote small C programs that read from stdin and print to stdout (we printed HTTP response, not just the HTML as per CGI spec). A website had lots of these small programs each doing one small thing and updated some database (sometimes that database was just a flat file).

Almost as soon as it was introduced people also started writing CGI scripts in Perl. So there was really no transition period between C programs and scripting languages. People simply stopped writing CGI scripts in C because it was faster to do so in scripting languages.

Solution 2 - Html

Server side was actually always in the picture.

The Apache HTTP Server was available since 1995, and in 1996 it also had Perl support (which was used as a server-side programming language).

JavaScript was created in 1996 and Netscape was the first browser supported the client-side language (other browsers vendors implementations were based on the work that was done in Netscape).

In 1993 the Mosaic browser is released with support for images, nested lists and fill-out forms.

Basically - every HTTP server that could handle request and pass it to some application (no matter in what language that application is written in) is a server-side application. It can be written in scripting language (Perl/Python/PHP/Ruby), high-level language (Java/C#) and if you really want - even assembly. All you need to do is make sure you "follow the protocol".

Solution 3 - Html

JavaScript wasn't so advance (hell Ajax wasn't even out yet). So it was pure server-side. Mostly CGI (being Perl) and PHP.

There was also Coldfusion but wasn't a popular favorite.

Eventually, at the end of 1999 and early 2000s ASP.NET (aspx) and JavaServer Pages (jsp) came out, although a lot of commercial sites used aspx and jsp for obvious reasons.

Note, Java applets also existed (mostly for rendering though) but had to be separately downloaded and supported by the browser.

Solution 4 - Html

Additionally, I stumbled on an interesting piece of history on Wikipedia. HTML forms could also be sent by e-mail, using a mailto: address in the target attribute. Didn't seem to be popular, but still cool!

Quoting the Wikipedia article:

> User-agent support for email based HTML form submission, using a > 'mailto' URL as the form action, was proposed in RFC 1867 section 5.6, > during the HTML 3.2 era. Various web browsers implemented it by > invoking a separate email program or using their own rudimentary SMTP > capabilities. Although sometimes unreliable, it was briefly popular as > a simple way to transmit form data without involving a web server or > CGI scripts.

And RFC 1867 (November 1995):

> 5.6 Allow form ACTION to be "mailto:" > > Independent of this proposal, it would be very useful for HTML
> interpreting user agents to allow a ACTION in a form to be a
> "mailto:" URL. This seems like a good idea, with or without this
> proposal. Similarly, the ACTION for a HTML form which is received via > mail should probably default to the "reply-to:" of the message.
> These two proposals would allow HTML forms to be served via HTTP
> servers but sent back via mail, or, alternatively, allow HTML forms
> to be sent by mail, filled out by HTML-aware mail recipients, and the > results mailed back.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJames JonesView Question on Stackoverflow
Solution 1 - HtmlslebetmanView Answer on Stackoverflow
Solution 2 - HtmlDekelView Answer on Stackoverflow
Solution 3 - HtmltfontView Answer on Stackoverflow
Solution 4 - HtmlBaptiste CandellierView Answer on Stackoverflow