Frequently Asked Questions - Web Pages

1. How do I create web pages?

The easiest way to get started is to check if your word processor can save a document as a web page.  Microsoft Word, for example, has a Save as Web Page... option under the File menu.  Consult the documentation for your software about how to do this.  As you become more experienced, you may want to use a program with more features, such as Microsoft FrontPage or ClarisWorks HomePage.  If you don't have a program that can create web pages, you may look online at a site like www.download.com for commercial, shareware and free HTML editors.

2. How do I upload web pages?

A simple way to create folders and upload web pages online is to visit www.cune.org and click the link for Manage Web Pages.  After logging in, click the green Upload Files and select up to 6 web pages to upload at one time.  To create a folder, type the folder name in the box to the left of the green New Dir and click New Dir.  To open the folder after it has been created, click its name and then upload web pages or create subfolders.  To return to the top or root folder, click root on the Current Directory line.  To rename or delete a file or folder, click the checkbox to the left of the names and then click the yellow Rename or red Delete.  When you are done, click the gray Logout.

Web pages may also be transferred using FTP (file transfer protocol).  Many web page design programs already have that capability.  Microsoft FrontPage, for example, allows you to "publish" your web site to "ftp://www.cune.org".  Consult the documentation for your software for further details.  You may also find commercial, shareware and free FTP programs online at a site like www.download.com.

3. How should web pages be named?

The default or home page should be named index.html (or index.htm).  Document and folder names are case sensitive.  All other web pages may be named however you like, but they should end with .html (or .htm).  It is best to limit characters to the alphabet, digits and underlines, for example, example_info3.html.

4. How do I access my web pages?

Simply add your account name to the end of the web site URL.  For example, http://www.cune.org/John.Doe/.  This assumes that you have created the default document index.html.  To access a specific document, you must supply the document name, for example, http://www.cune.org/John.Doe/example_info3.html.

5. Why can't I see the latest changes to my web pages?

In some cases, you might upload a new version of an existing web page, but when you type the URL in the browser, the old version of the web page is displayed, instead.  The problem is that the web browser temporarily stored the old web page on your computer when you viewed it so that displaying the web page would be faster the next time.  Try clicking the Refresh (Internet Explorer) or Reload (Netscape) button to update the page.  If that does not work, you can force the browser to fetch a fresh copy of a web page directly from the server.  Hold down the control key (ctrl) and click Refresh (Internet Explorer) or hold down the shift key and click Reload (Netscape).

6. Can web form results be mailed to me?

Yes, you may create web forms to gather information from people and have it sent to you in email.  Design your web form to call the FormMail script with your address as the recipient.  If your account name was John.Doe, a minimal form would look like

<form method="post" action="/misc/mail/cgi/FormMail">
  <input type="hidden" name="recipient" value="John.Doe@cune.org">
  <input type="text" name="feedback"><br>
  Please enter your comments<br>
  <input type="submit">
</form>

7. What hidden fields does FormMail recognize?

The default settings for FormMail will meet most needs.  However, you may send additional configuration information to FormMail through hidden fields in a web form.  Below are the fields recognized by FormMail, their definitions and, in some cases, an example of how to use the field.

recipient - Up to 3 cune.org addresses, separated by commas, that will receive a copy of the results.

<input type="hidden" name="recipient" value="John.Doe@cune.org,Jane.Doe@cune.org">

subject - The subject line of the email you receive. Useful if you have more than one form.

<input type="hidden" name="subject" value="Web site comments">

redirect - If present, a URL where the user will be redirected after the form is submitted. This could be a customized thank you or a second form to fill out. If not present, FormMail will automatically generate a "success" page telling the user that the submission was successful.

<input type="hidden" name="redirect" value="http://www.cune.org/John.Doe/thankyou.html">

If FormMail automatically generates a success page, you may modify its appearance with the following fields.

bgcolor - Background color for the success page.

background - URL of the background image for the success page.

text_color - Text color for the success page.

link_color - Link color for the success page.

vlink_color - Visited link color for the success page.

alink_color - Active link color for the success page.

title - Title for the success page.

return_link_url - URL for a link on the success page the user can click to continue.

<input type="hidden" name="return_link_url" value="http://www.cune.org/John.Doe/Page2.html">

sort - Order in which fields will appear in email. The value may be "alphabetic" for alphabetic ordering of fields or a specific order indicated by "order:" and a comma separated list of field names.

<input type="hidden" name="sort" value="order:name,email,age,comments">

print_config - Used for debugging. Directs FormMail to include the values of the hidden FormMail configuration fields in email along with the other form fields. To include the settings for the "title" and "sort" fields,

<input type="hidden" name="print_config" value="title,sort">

required - The list of fields that must be filled in before the submitted form will be accepted. If any of the fields are blank, an error will be displayed, and the user will be asked to go back to the form.

<input type="hidden" name="required" value="name,comments">

missing_fields_redirect - If present, a URL where the user is redirected when a required field is blank. Useful for finer control over the error the user sees when a required field is blank.

env_report - A list of CGI environment variables that should be included in email.  Current choices include REMOTE_HOST, REMOTE_ADDR and HTTP_USER_AGENT.

print_blank_fields - Directs FormMail to include all fields in email, even if the value is blank. Useful if you print the email and use it as a standard form.  Missing values can be written in later.

8. May I write CGI scripts?

Yes, you may write CGI scripts in perl.  CGI scripts provide a means to generate dynamic web pages by running a program.  Place your CGI scripts and data files (if any) in a directory named cgi.  Scripts must be executeable by the owner (-rwxr- - r- - or chmod 744).  An extension such as ".cgi" or ".pl" is optional.  The name of a script should otherwise consist of letters, digits, underlines or dashes.  The initial line of the script should be "#!/usr/bin/perl" or "#!/usr/bin/perl -w".  Take the utmost care to write scripts in a secure manner.

9. What are the limits for a CGI script?

In order to protect the server from poorly designed CGI scripts that might consume all available system resources, limits are placed on a script when it runs.  Limits at the time this is written include use of up to 10 seconds of CPU time, writing up to 256KB to a file and using up to 16MB of memory.  If a script exceeds a limit, it will be terminated.

The actual requirements of a typical script are low.  Most scripts execute in one or two seconds, do not write much information to a file (if any) and do not require much memory.  More memory is required as more modules are loaded or as more data is stored in memory.  To lower memory requirements, check whether you need to load all of the modules at one time.  Determine if there is a way to read and write only necessary information in a file rather than the whole file.

10. What can my CGI script access?

A CGI script is run in a protected environment under the full perl interpreter (not mod_perl).  The script has access to all of the functions and modules offered in perl.  A script does not have access to any system-level programs, system files or shell interfaces.  A script is able to access all of the files in the cgi directory and all of the web pages that are one level up from the cgi directory (i.e., everything in your home directory).

11. What perl modules are installed?

All of the common perl modules are available.  If a module you would like to use is missing, send a request to email@cune.org to install the module.  If it is a module that we would support, we will install the module.

12. May my CGI script send email?

Yes, but it is recommend that web forms use FormMail whenever possible in order to avoid security problems.  Since no system programs, including sendmail, are available, your script must send email using SMTP.  The simplest method is to use the Mail::Sendmail module, which should meet most needs.  For more extensive features, use Mail::Message.

Scripts are not allowed to send email directly to the Internet.  Instead, email should be forwarded to www.cune.org, and the email will be delivered for the script.  The sender address of the message must be your cune.org address.  Carefully check that your script does not allow spammers to relay email.

13. What if my CGI script has a problem?

Computing Services does not provide consulting services for writing scripts.  You should read the documentation, check online sites for advice, consult the author of the script (if not your script) and debug your script with the help of a friend.  Fatal script errors produce generic error web pages like "Internal Server Error", which are not very helpful.  The first step in tracking down such a problem is to load the CGI Carp routines in order to display more information in your browser window.  For example,

use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);

That is all you need.  When you access your script, the actual error message should now be displayed.  If you want to see warning messages as well, a little more work is required.  You must load the routines to handle warnings, and you must turn the warnings on after sending the page header.  For example,

use CGI (:standard);
use CGI::Carp qw(fatalsToBrowser, warningsToBrowser);
print header( );
warningsToBrowser(1);

Read the documenation for the perl module CGI::Carp for more details, including using carpout( ) to manage error messages yourself.  If you wish to keep your debugging simple, your script can open a log file and print lines of information to the file as the script runs.  Then, you can examine the log to see how far your script got before it stopped.  Keep in mind that there is a limit to how much information a script may store in a file each time it is run.

If, after debugging your script, you believe that a problem is due solely to the configuration of the server, reduce the script to the minimum number of lines required to reproduce the error and send the script to email@cune.org along with a detailed description of the problem.  We will investigate the problem as time permits.  If it is determined that the problem is in the server configuration, we will attempt to modify the configuration, if possible.