In this section we have grouped together a series of frequently asked questions regarding web sites on the OUCS 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?
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?
You can find out what information is available to web servers about you and your system by clicking on this link
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. OUCS has no control over this practice.
The OUCS servers
All the OUCS 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.
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
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 OUCS web server (if you are using a different server contact that system's sysadmin):
linux.ox.ac.ukusing your Oxford username and password
% htpasswd [-c] passwordfile username
% 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
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
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-userAuthName 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"
.htaccesshas got world read access:
.htaccessto 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 OUCS 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 OUCS 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. OUCS 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 here: Generic Perl Scripts.
12. Sending email from your CGI script
A secured subroutine is available which allows the sending of mail from a CGI program. The syntax is:
mail('email@example.com', 'Test mail', "Hello
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.
13. 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:
Opening files for reading/writing is restricted. The "open" command is subject to the following restrictions:
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 OUCS rules.
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
To sort into increasing numerical order use
If you want a decreasing order, then just use the standard Perl reverse operator on the resulting array.
If it is raw text then
14. 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:
.htaccessfile using a text editor
myusernameto your username and replace
www.my-new-site.comwith the real location of your site:
Redirect /~myusername http://www.my-new-site.com/