In this section we have grouped together a series of frequently asked questions regarding web sites on the personal pages web server. If you cannot find the answer to your question here, please send your question to us via the Help Pages and Form.

1. What advanced web programming is allowed?

There are many restrictions governing the use of the personal pages web server because of security issues. The two activities the web server will allow are:

2. Do you support PHP?

We do not currently offer a PHP scripting service on this server. If you need PHP for your work please see NSMS who do provide this as a paid for service.

3. What are web access log files?

During your travel around the Internet, you will visit many different servers around the world and, unknowingly, leave a digital trail of your surfing. This is because web servers collect and log information about you and your web client system. There are valid reasons to keep such logs including:

  1. Help to track security breaches
  2. Counting how often documents are accessed
  3. Recording types of browsers being used

Web Client Report

Information collected in web logs is purely for system related reasons. No specific details of an individual's use of computer systems are not made publically available. However, some server owners do allow third parties access to this information. IT Services has no control over this practice.

The IT Services servers

All the IT Services web servers record information on which files are accessed, when and by whom. This last item consists of the IP name and number of the computer you are using to access the web, together with your user name on that system (if available). IP naming schemes used for computers can allow an individual users identity to be determined.

Other Colleges and Departments of the University also maintain log files. The University IT Committee recommends that these log files are not made available in a form to identify individual users.

4. How do you restrict access to web pages?

It is sometimes necessary to restrict access to part or all of your website because subsections may still be in development or because you only want people using machines with an Oxford IP address seeing your pages. You may want to restrict access to specific users by setting usernames and passwords if you are running a specific course for instance. All these scenarios can be catered for, by following the instructions below.

Restricting access by IP name or address

Every browser accessing the web has an IP (Internet Protocol) name (e.g. (rabbit.oucs.ox.ac.uk) and a number (e.g. 163 1.32.180). Both can be used to restrict access to your pages. It is important to realise that you protect a directory and its subdirectories, not individual pages. To do this you have to create a file called .htaccess which contains an access control list (ACL). This file should be placed in the directory which you wish to protect.

For instance to protect a subdirectory called 'papers' so that it can only be accessed by machines in the Oxford domain you need to add the .htaccess file to that subdirectory. It should contain the following information:

  Order deny,allow 
  deny from all 
  allow from .ox.ac.uk 

This works in two steps. First it prevents access for anyone but then allows access to the directory to machines in the oxford domain. You can further refine this statement by changing the Allow from line to read:

Allow from oucs.ox.ac.uk

Only machines visiting from the oucs.ox.ac.uk domain will be allowed to see the directory pages. You can specify more domains by adding further 'allow from' statements to the file. Instead of using the IP name you could use the IP number to get the same result.

5. What about restricting access by username/password?

It is also possible to protect Web directories by username/password combinations. In order to set this up you should follow these steps if you using the IT Services web server (if you are using a different server contact that system's sysadmin):

  1. Log in to the Linux system linux.ox.ac.uk using your Oxford username and password
  2. Create a file containing usernames and encrypted passwords:

    % htpasswd [-c] passwordfile username

    For example,

    % htpasswd -c /web/users/$USER/cgi/myusers.passwd fred
    Adding user fred
    New password: rubbish (not echoed)
    Re-type new password: rubbish (not echoed)

    The file used to store the passwords should not be in the accessible document tree; the cgi directory is a good location (on linux.ox.ac.uk this can be accessed as /web/users/$USER/cgi).

    The -c flag is only needed the first time that the command is used.

    You will be prompted twice for each user's password. You will need to use the htpasswd command for each user you want to add.

  3. Make sure that the file which holds the passwords is world-readable. For example:
    % chmod a+r /web/users/$USER/cgi/myusers.passwd
  4. The commands to activate the password file are placed in the .htaccess file. As before, this file needs to be placed in the directory where access restriction is to start. For example:

    AuthType Basic
    AuthName my-private-webpages
    AuthUserFile /web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi/myusers.passwd
    require valid-user

    AuthName can be anything meaningful to the people that need to supply a username and password (note that a value is required). If the name contains spaces, it must be given in quotes. Using the above example, when the username is requested the browser will display "Please enter username for my-private-webpages at users.ox.ac.uk"

    AuthUserFile is the location of the file you created in step [1]. This file is actually held on the web server. Therefore you need to give it a path name which is meaningful to the web server:

    1. Type webhome to obtain the path of your home filestore on the web server. For example:



    2. The path to your cgi directory is then the value returned by "webhome" and with "cgi" appended:

    3. The full pathname then becomes:

  5. Make sure that .htaccess has got world read access:
    % chmod a+r .htaccess
  6. If you want to authenticate by both username/password and client host address, you can use the Satisfy directive in .htaccess to specify whether access is allowed if either test is passed, or if both must be passed (the default).

6. Making a custom error page and redirect

In the "public_html" folder on your IT Services webspace, create a folder called "error"

In this folder, create a new html file, and put in the META tag to redirect to the new URL, e.g.:



<META http-equiv="refresh" content="0;url=http://www.my-new-site.com/">



This site has moved. If you do not get redirected to our new site, click <a href="http://www.my-new-site.com">here</a>.



Save this file as "error404.html" in the "error" folder under "public_html"

Go back up to the "public_html" folder, and create a file named .htaccess, with the following line in it:

ErrorDocument 404 /~USERNAME/error/error404.html

This redirects the browser to the error page you created above, which in turns redirects the browser to your new site. You have to include /~USERNAME (which is your Oxford username) because the .htaccess file needs absolute paths, and the Oxford username is part of this.

Internet Explorer by default displays "Friendly HTTP Error Messages" if the content of your custom error message is less than 512 bytes. So, in the example above you must make sure the page size is greater than 512 bytes. One way would be to add a suitably sized graphic.

7. How can I set up a feedback form?

You will need to create a form and link to a CGI script which will process the form for you. The script will also validate your form before allowing it to be sent to your email account. This script is located at:


and is available to all web site owners who have an Oxford University email address.

A short tutorial on using this script in a form is provided in the HTML tutorial.

8. What are server side includes (SSI)?

Server side includes are a special type of HTML comment that tells the web server to dynamically generate data and place it in a web page. You can use SSIs on your IT Services web site by naming your files as ' .shtml'. A general tutorial on SSI is available at: http://www.webreference.com/programming/ssi/intro/

9. What is CGI?

The Common Gateway Interface or 'CGI' technology is a well established method for web site interactivity. It is not a programming language itself but a standard method to allow external programs to run on a web server. The external programs can be written in many languages, but the most common one is Perl. IT Services recommends the use of 'Safe Perl' to build CGI programs. More information on the Perl language can be found on the Perl web site: http://www.perl.com

10. Can I write my own CGI programs?

Yes you can. However, we only allow the use of the 'Safe Perl' language to build CGI programs. More information on the Perl language can be found on the Perl web site: http://www.perl.com

11. Do you have any generic Perl scripts available?

Yes, some useful but poorly documented examples are available as a downloadable zip file. This contains:

  • mailme.pl
  • saveme.pl
  • searchme.pl
  • .htaccess

11. Sending email from your CGI script

A secured subroutine is available which allows the sending of mail from a CGI program. The syntax is: 


For example, 

    mail('foo@bar.baz', 'Test mail', "Hello world\n")

        or oops("mail failed");

Note that @ interpolates an array when used in double quotes ("") (unlike in perl4 which tried to guess whether you wanted to interpolate or have a raw @ in there). If you want to hard-wire an email address with an @ in it then either use single quotes or prefix the @ with a backslash ("$user\@wherever"). Note also that you gather the whole message together into one string to pass as the third argument.

Email sent in this way will have a sender address of your own University email address. 

12. Writing your own Safe Perl.

Only a restricted set of the Perl language is available: usage of unsafe features (even within eval statements) are trapped and the program is not run. There are many Perl operators not available to the CGI directory in which your program is run. These include the operators that could affect the operating system. The following list is not exhaustive but includes the most common excluded operators:

  • system, `backticks`, exec, fork, syscall, signal handlers, pipes (including open(FOO, "|bar") and open(FOO, "bar|"))
  • network access (socket, bind, connect, ...)
  • File munging (rename, link, opendir, chown, ...)
  • System V IPC (shared memory, message queues, semaphores)
  • File tests (-r, -w, -l, ...)
  • Calling perl on other files (require, use, do 'file')

Opening files for reading/writing is restricted. The "open" command is subject to the following restrictions: 

  • Files opened for reading must be owned by the user. Your CGI program is run with a current directory of ~/cgi/. It is strongly recommended that you use relative pathnames (for example, "../public_html/foo").
  • Files opened for writing must be opened by using a filename containing no "/" characters. The filename is taken to live in the directory ~/cgi/out and the file must already exist at the time the open is performed. It can be a symbolic link if desired.

Once you have written and debugged your CGI program, put it in ~/cgi/bin (creating that directory if necessary). There is no need to include a leading "#!" line, nor will one be honoured if you do. Supposing that your username is quux and your program is called foo, the URL to run your program is


When the web server runs your program it will run it with the privileges of your Oxford account.

Any use of a masked operator in your Perl program will trigger a compile time error (which your browser will display) and the program will not run at all. A "masked operator" is an operator which is restricted but which, unlike "open", is not aliased to a secure sanitised version. The error message will be something like opname trapped by operation mask at line ... where opname is replaced by the name of the offending operator.

Please be aware that, even with the restrictions on what your program can do, it is possible that someone out on the web will be able to persuade it do something you weren't expecting. Even with the file limitations, for example, your program may have a bug which lets someone see the contents of any file you own. You are responsible for the CGI programs you write and you must ensure that your CGI programs do not contravene IT Services rules.

Sorting lists

For sorting lists, the perl built in sort operator is masked (since inconsistent comparison subroutines can cause the underlying C library qsort function to core dump). Two functions are provided for sorting lists in the two most common collating sequences: ASCII and numeric. To sort an array @unsorted into increasing ASCII order use 

    @sorted = sort_ascii(@unsorted);

To sort into increasing numerical order use 

    @sorted = sort_numeric(@unsorted);

If you want a decreasing order, then just use the standard Perl reverse operator on the resulting array.

Common problems

  • Every CGI script must output at least one header line. If your program generates output, it needs a Content-type line indicating what kind of document (MIME type) it is producing. If your script outputs an HTML page, the correct format is: Content-type: text/html

If it is raw text then

Content-type: text/plain


  • The final header output (even if it is only Content-type:) must be followed by two pairs of <CR>/<LF> or, although less correct, two line feeds (ascii 10 decimal). This means there must be a blank line after the last header line.

13. Re-directing to a different site

If you have moved your site from users hosting to a different one either inside or outside of the university you will probably want to re-direct your site visitors to the new location. This is easy to do by:

  1. create a .htaccess file using a text editor
  2. Type in the following code changing myusername to your username and replace www.my-new-site.com with the real location of your site:

    Redirect /~myusername http://www.my-new-site.com/

  3. Save and upload to your users webspace. Visitors to your users web space will now automatically be re-directed to the new location.


Service area: 

Written by IT Services. Latest revision 16 October 2015