Re: NCSA Server (1.3) and ScriptAlias problems

>The issue is how to deal with a ScriptAlias that is serving up multiple
>HTML files, e.g.:
>
>        ScriptAlias /bgc/ /xxx/bgc/access/
>        ScriptAlias /bgc /xxx/bgc/access/
>
>In particular, the problem is that the script can't tell the difference
>between being invoked with or without the trailing slash, and the
>difference is quite critical. I suspect that there should be a difference
>in PATH_INFO, but there isn't. Is that a bug, or is there another better
>way of dealing with this?

I think you are using ScriptAlias in a way the authors of the NCSA server
did not envisage, and hence are encountering a bug.

A config option like
   ScriptAlias /foo/ /path/bar/
was intended for aliasing _directories of scripts_, not individual scripts.
Thus a typical usage would be for an access to /foo/script.pl to cause the
server to execute /path/bar/script.pl as a CGI script.

Use of ScriptAlias as you describe, e.g.
 ScriptAlias /foo/ /path/script.pl/
might work, but cannot be relied on with the NCSA server.

This has been fixed in the Apache server (which is derived from the NCSA 1.3
code):
 ScriptAlias /bgc /xxx/bgx/access
would do exactly what you want.
Accesses to /bgc would invoke the script with a NULL PATH_INFO
Accesses to /bgc/ would invoke the script with a PATH_INFO of "/" etc.

>1. If you don't have the version with the trailing slash, the (non-trivial
>number of) people who hit the site without it will get a file not-found.
>This isn't the case when the server is handling access, but it is the case
>when you are using a ScriptAlias.
Bug.

>2. If you point them both at the same script, the script can't tell whether
>it was invoked with or without the slash (I believe there ought to be a
>difference in PATH_INFO, but there isn't).
You don't need two aliases, but just one.

>3. The script can do one of two things when faced with a directory name
>with no index.html. It can't do a redirect to the index.html file (which
>takes up a fair amount of time, and of course additional server resources),
>or it can just server up the file.
I won't assert what you _should_ do, but common practice is to return
the file without doing a redirect.

>4. If it serves up the file, the client will get all the relative links
>wrong. It's URL will look like "http://www.xxx.bar/foo", it will assume
>that "foo" is a file and make all links relative to the link instead of
>"foo/". You can try and fix this with a <base href=3D"correcturl"> in the
>index.html file, but that doesn't work for all browsers.
Common practice would be to redirect to the URL with the trailing slash,
if one is missing. However, I think you will find that returning a
BASE tag will work for the vast majority of your users. (N.B. but not
necessarily browsers.)

>5. My solution therefore, is to have a separate script, bound to the
>non-slash version of the name, which does nothing but redirect the user to
>the correct URL. Ugly, but there it is.

For apache, you would only need one script, which could check for a NULL
PATH_INFO and do a redirect in that case.

 David Robinson.

See <URL:http://www.apache.org/apache/> or
<URL:http://www.hyperreal.com/apache/> for details of apache.

Received on Thursday, 11 May 1995 06:05:29 UTC