- How do I map between URLs and filenames?
- How do I get space on one of our web servers?
- How do I install my CGI scripts?
- Can I run my own HTTP server ?
- How do I get a directory index to happen for a directory?
- I can't seem to write to file "xxx," and I think I should be able to. Why?
- I don't want my document to be cached. Can I control that?
Information on home pages is in the Home Page FAQ.
(Much of this information is obsoleted by the deployment in 2012 of a Drupal CMS (content management system) for core departmental content.)
The following table shows how files are named by a URL on
If you want space for project-related WWW material, and your project already has a project disk, you are encouraged to use this disk to store WWW-related files. The project disk may already have a top-level WWW area for a project, or you may need to set one up. If you create a new one, let webmaster@cs know about it, and it will be added to the index of research projects.
If you don't have a project disk, or want create a web covering
material that is relevant to the department, send mail to
support@cs, and a directory will be set up for you, probably
If for personal use, see User CGI for CSE Users.
If you need to use CGI scripts for some department-related work, support will create a directory for you in which your scripts can be executed. Without this, it is "impossible" for you to use CGI scripts. By default, access to these CGI scripts is limited to machines within the department only - if you want or need wider access to them than this, then expect to have your program subjected to fairly stringent scrutiny, and the possibility that you will need to rewrite it or modify it before wider access can be granted.
Yes, if you need to. We ask that you discuss running your own server with the Compute Science Lab staff, first.
To control who can access your stuff, or from where, you will need an access control file.
This file is called
.htaccess, and controls access to
your web document hierarchy (and, if other goo is added, some other
characteristics of the way your content is served). For example, to limit
access to your web files to people within the department, you need create a
.htaccess file in your main WWW directory.
Please make sure your
.htaccess file is world-readable;
also make sure the last line of the file is
newline-terminated, else the server will ignore it.
The most significant aspects of the file's contents look like this:
order deny,allow deny from none allow from cs.washington.edu
In the example shown, access is granted only to people browsing from
If you want different access controls for subdirectories in your own
web, create a
.htaccess file in one or more of the
relevant subdirectories, with the appropriate commands in it.
To read more about access control files, try the Apache httpd documentation.
http://www.cs.washington.edu/people are a number
of subwebs that contain an index of various categories of people
within the department, such as graduate students, undergraduates,
faculty and staff.
You might expect that you could simply send mail to
webmaster@cs and ask to be added to one of these lists.
Alas, you'd be mistaken.
Graduate and Undergraduate Students Listing
It is a violation of the University of Washington's privacy regulations for us to disclose your status as a student here. Therefore, we cannot add your name to this list (or remove it) without your explicit permission. However, electronic mail is (1) too time consuming to use for this purpose-- it requires manual intervention on the part of the webmaster for every message and (2) grossly insecure. How insecure is insecure? Lets just say that its possible to fake any sender's address without any special privilege at all.
Because of all this, we use an automated procedure that allows you to automatically add/delete yourself to these listings.
For faculty and staff, the index is generated nightly from a database. There is, of course, no policy against disclosing the identities of faculty and staff. If you have a web page, it will be linked.
The answer to this differs somewhat depending upon your role at the University.
If you are an employee of the University-- faculty or staff-- your content should be restricted to that directly related to your job function. A strict interpretation of policy would forbid anything of a personal nature.
If you are a student, policy is less severe with regard to personal content.
Under no circumstances, though, can any user use University equipment for anything that could be construed as commercial purposes, such as offering items or services for sale, or for partisan political purposes, or for unauthorized distribution of copyrighted materials.
Here are relevant links to documents offered by the University of Washington:
We used to encourage people to put their email address on home pages, but that was before robots started harvesting those addresses for spam-sending purposes. If you'd like to offer a link for sending email, we think it safe to do so by linking to our email-sending CGI script, which doesn't require you to put your full email address on your page. Here's an example of how to link to that so that mail is sent to user farnsworth with a subject of Hello, friend:
<a href="/htbin-post/unrestricted/mailto2.pl?to=farnsworth;sub=Hello,+friend">Email me!</a>
As you can see, that's anchored on the words Email me!.
The CSE web includes lists of the faculty, staff and students in the department. There are internal and public versions of each student directory. The internal version is accessible to all students in your own program, and the public version is accessible to anybody.
To protect your privacy (and to comply with federal privacy legislation), we allow you to control which (if any) of your personal information is displayed. To do so, please visit the internal directory page corresponding to your program: http://norfolk.cs.washington.edu/htbin-php/students/ugrad/ for undergrads, http://norfolk.cs.washington.edu/htbin-php/students/grad/ for full-time graduate program students, or http://norfolk.cs.washington.edu/htbin-php/students/pmp/ for professional masters program students. There, you will find a link to a form you can fill out to set your directory display preferences.
The faculty and staff indices are maintained automatically. Please send mail to webmaster if you find that you should be but are not yet listed in the appropriate index.
When somebody tries to load a document specified by the URL that points to a directory, such as:
http://www.cs.washington.edu/homes/youruserid/our HTTP server will look for a file in that directory called
index.html, which is intended to act as index to the web "below" it. If this file does not exist, our server will deny access to that directory.
If you want your home page to play the role of this "index file", then
you can either rename it or link it to the name
% cd /homes/gws/userid/www % ln -s home.html index.html(you should replace
useridwith your own userid, of course).
You might want to have an alternate file as the index, since you might
have areas of your own web that you'd like to point people at, which
is not really the function of a home page per se. The contents of an
index file are up to you, but it must be called
index.html. It is an HTML file just like your home page,
and probably makes strong use of the construction:
<ul> <li> <a href="subdirOfmyWWWdir/name.html">Something Great</a> </ul>
Note the use of a "relative" URL above. By using this, instead of an absolute form (which would start with something like "http:"), you are creating a link to a document whose location is inferred relative to the one in which the link appears. This ensures that the links to your other documents remain valid even if your tree moves (or if the webmaster rearranges the top level of our web).
This is a hard problem to which the answer is, more or less, "you can't." You can add hints to a page, but some browsers will ignore such hints no matter what. One trick is to enable SSI (server-side includes) for the page; documents that are processed for SSI directives are never sent with a "Last-modified" response header field, which encourages browsers to reload. Another hack is to send the content as CGI output; the output of CGI scripts is never supposed to be cached. Finally, and most orthodox, you can use META tags in the HEAD of your document:
<meta http-equiv="Cache-Control" content="no-cache">and/or
<meta http-equiv="Expires" content="0">which latter is reportedly ignored by some browsers and isn't strictly legal HTTP/1.1 in any event.