the server doesn't have to. It's up to the client to build the url with
the information the server gives, and then ask the file with that url.
As far as I remember it's perfectly legal for the server to give a
relative url. So, when the client loads the page
http://www.mindprob.com/bgloss/cables.html, and in that page there is a
link to ../jgloss/rs232c.html, the client itself should know, when the
link is clicked, that it has to ask the url
http://www.mindprob.com/jgloss/rs232c.html. The client knows it because
it builds the url relatively to the location of the page that has just
been loaded. The server, on the other side, afther the page cables.html
has been delivered, doesn't care anymore.
This is one of the reasons why I would say that the problem is more
likely on the server. The value of the referer makes me think too.
I have the impression that what happened in that case is the following:
- someone went on google, and found a link to your page
- asked the page to your server
- for an unknown reason the server seems to parse the page, and try to
access the page pointed to by the link

So the message on the log was probably written *before* the client
actually got any page from your server

   When an HTTP client connects to an HTTP server, one of the operations a
client may perform is a GET operation. This is the operation typically used
to retrieve a web page. The GET operation takes one parameter, which is some
identifier for the resource to get. There is no concept of "absolute" or
"relative" path in this case, and the identifier does not even need to
reflect a path in any sense (though in most implementations, the identifier
is a path describing path to the desired HTML file).

   A web browser does not only act as an HTTP client, but also as an HTML
parser and renderer. HTML does define a concept of a relative URL. It is up
to the browser to note where the HTML file was retrieved from, and from
there, to translate the relative URL into an "absolute" path that is valid
for a GET operation.

   It is not uncommon for the webserver to do some semi-complex
manipulation on the argument to GET to determine what file to retrieve. For
example, the server might respond to a request like "GET ~owong/foo.html" by
loading the file locate at "/usr/home/owong/wwwroot/foo.html".

   Similarly, it might respond to a request like "GET me_a_random_number"
by randomly generating a number, and returning that number, and not actually
access the file system at all.

   - Oliver

Just curious... If I browse straight to
"http://mindprod.com/bgloss/cables.html" (not from google), I see "[an
error occurred while processing this directive]." besides the "More
Than You Wanted To Know About RS232C" link. What is that? Are you
building the page dynamically?