This explains the most direct way to create a web form on the IPAD-OS WebLite server to accept information from a user and put it into an email to you in three easy steps. The WebLite forms processing CGI has loads more power and flexibility but that is for another time.

Step 1.

It all starts by you choosing a name or keyword for your web form. Keep it short and simple.

In my example below I'm making a comment form so I use the name George. I could use the word comment but that would be boring.

The name is going to be part of the web form action URL so it must follow the same naming rules that web pages follow. In simple terms this means the name can only use letters, numbers, period, dash and underscore characters. I like to keep things extra simple and just use letters.

Step 2.

Now that we have a name for our form we need to tell the IPAD-OS WebLite server about it. This requires peeking into the IPAD.CTL file for the WWW_LITE line defining our web site and then looking for the FORMS= field. This field points to the INI file and will look something like this.

Pull out your favorite text editor, open the INI file and paste the following block of text into it. If the INI file is not empty, take a quick look around to make sure there is no other block with the same George name. Each block must have a different name between the square brackets.

Now you have some choices where you want the email to go and what web page to show to the user after they click the submit button on the web page.

• From= - Don't pay too much attention to this field unless the To field below is your customer and you want replies.
• Sender= - For now always make this field match the From field.
• OutputStyle= - Leave this one as Text until you get more comfortable with web forms.
• SendURL= - This is the Thank You web page the user will see after clicking the Submit button on your web form. It can point literally anywhere on the Internet or to a page on your web site. Either way it must be a fully qualified URL with the protocol and domain name.
• Subject= - This is the subject line of the email. I like to add square brackets with something telling me where the email came from. This also makes it easier to build a filter in my email program so all web form mail goes to the same place.
• To= - Finally this is the address to receive the email.

There are two parts we need to write down for the next step:

1. The Name from step 1
2. The SendURL page name from step 2

Save the INI file. We are done with this step.

Step 3.

I'm not going to tell you how to build a web page or a web form, just the action line at the top of your web form because it is the only part that is different between any other web server and the IPAD-OS WebLite server.

Take a look at the action field. There are three parts to this URL each separated by slash marks.

1. The first part must contain the exact text cgi-. The rest can be whatever you want. Be creative if you want.
2. The second part must contain the word form so anything like WebForm or myformat works the same.
3. The third part must contain the Name selected in step 1 above. Take another look at the example above. The action name is not the same as the HTML name= field. This is Ok. The WebLite server only cares about the action field.

Note the IPAD-OS WebLite server, at least up through version 9.0, only supports post method for this CGI. If your web form uses the GET method, change it to POST now.

Now make sure the Thank You page defined in step 2 exists and you are done.

Creating additional forms in the INI file is nothing more than a quick copy and paste away, but I tend to reuse a lot of my forms by creating some bit of uniqueness using hidden form fields rather than a new form for each page on the web site.

The really good news is this web form processing CGI is completely immune to exploits and when configured this way can never be used to send mail to any address not listed in the INI file. To my knowledge the IPAD-OS WebLite server has the only form to email gateway with a proven track record of being immune to all exploits since 1995. No other web server at any price comes close to that track record.

First published 2012-12-06. The last major review or update of this information was on 2014-03-07. Your feedback using the form below helps us correct errors and omissions on this page.