(Article originally found here)
Every website out there that wishes to interact with its visitors uses a form. This article serves to highlight the growing problems and misconceptions of form handling. Many forms out there fail for one reason: The web designer has incorrectly assumed what a visitor has installed.
HTML Forms are the most common feedback mechanisms on the web today. They allow the site-owner to collect information about the surfer, for reasons of pure interest right through to nefarious schemes to swindle people's life savings (also known as Multi-Level Marketing and adult content sites). If you want to know something about a visitor to your site, you use a form.
Hand in hand with displaying forms follows a component to process or direct the input of this form. As behind every innovative man is a strong woman, behind every form there is a mechanism for retrieving, storing or assimilating the data - two sides of the same coin.
Normally behind every form is a server side script which takes the form data, via either a
post method (depending on the size and type of data being passed), collects the data and does one or more of the following actions:
"It works for me" Inexperienced web-designer
The third methodology has been taken up by enthusiastic web-authors, mainly because of its convenience and simplicity, and mainly for the mistaken belief that an action of mailto: results in the sending of the form data in a mail to the owner.
"It works for me", say the inexperienced author.
<form action="mailto:firstname.lastname@example.org"> looks very elegant a solution - so did the Titanic, and its captain didn't expect problems either.
Looking at the
HTML 4.0 specifications,
and especially at the exposition of the
shows that for the
action attribute should be a correctly formed HTTP URL. Anything other than a URL is undefined, thus the resulting action taken by browsers is completely random since browser designers are left to their own devices.
Microsoft's Internet Explorer when used with Outlook Express does produce the remarkable effect of sending the contents of the form via email to the address suggested in the form tag. Which is good for the newbie web-designer - Melissa and Love Bug worm-authors are equally happy with this close relationship between the browser and mail reader. This affinity is thus a good thing, and a serious fundamental security flaw.
Other combinations of browsers and mail readers produce one of the following effects:
Here's the result of using the Pegasus mail client to send email to an illegal address:
501 <email@example.com?subject=testing>: malformed address: ?subject=testing> may not follow <firstname.lastname@example.org -- What this suggests is that if the browser doesn't process the illegal address that includes '
?subject=...', doesn't strip off the illegal part, then the email goes South.
An author has no control over which browser the visitor uses. He/she can't be sure the
?subject address will work every time, when the page is being designed. Newbies beware.
Posted by Steve Grant
Never assume what the user has installed.
With so many possibilities of going wrong, all of them dependant on the user's set up; this form has broken one of the fundamental rules of web-design: Never assume what the user has installed.
The corollary the the first fundamental rule of web-design is: The server is the one tool a web-designer can trust. Since the web designer has the choice of where to host his pages, he therefore has the choice of what tools and interfaces he will use during site construction.
Translated to our problem at hand, form processing, the solution is blindingly obvious. Use a server side script to handle all the data from our form, and this script can then email all the details to the web-site owner.
The advantages of using a server-side process are:
Where do we find a server-side script to handle form submissions? There is a great CGI-resource on the web that has several formmail scripts that can be used.
One common punt by the inexperienced web-designer is that his web-host doesn't offer CGI facilities, so he is forced to use a mailto:. There is a reliable alternative for this problem, apart from moving to a different web-host. This alternative is the remotely-hosted formmail script - which is a script that is hosted on someone else's box. Two sites allow web-designers to use these scripts freely, they are Response-O-Matic and Freedback.
Copyright ©1999-2003 isolani