Searches, problems with (fwd)

Ray Stell (
Wed, 7 Jul 93 9:40:05 EDT

Forwarded message:
> From Tue Jul 6 20:12:30 1993
> Date: Wed, 7 Jul 1993 11:54:03 +1200
> From: Nathan Torkington <>
> Message-Id: <>
> To:
> Subject: Searches, problems with
> Two parts to this post -- an answer for Susan, and a discussion of the
> problem highlighted by Susan's post.
> Searching
> ---------
> The answer to your question, Susan, lies in the way that the clients
> and servers work. When the client finds an <ISINDEX> tag in a
> document, it knows it has a cover page for a search. When the user has
> entered keywords for the search, the client requests exactly the same
> URL as the cover page, but appends
> ?word+word+word
> to the end of it. This means that the *server* receives the URL
> /path/to/coverpage?word+word+word
> The default behaviour for an unmodified CERN server (as far as I know)

How does the ncsa httpd work? Is this documented?

> is to go ``this server doesn't allow searches'' whenever it receives a
> ?word+word style URL. In order to have your search activated, the
> server would need to call the shell script with the search keywords as
> arguments.
> What I did to get around it, was write my cover-page *and* the search
> module as a shell script which was then called by inetd. Instead of
> making a link to http://machine:80/document, I made a link to
> http://machine:9080/document (9080 being the port in inetd.conf).
> ----------
> This is an ugly hack! What I would much rather prefer to see is
> <ISINDEX HREF=http://machine:9080/document>
> where the URL after HREF= is the bit to append the ?word+word to.
> Also, a version of the CERN server that can be configured (in the
> httpd.conf script) to define allowable suffixes for the search
> programs, eg
> search .p
> search .sh
> Then, when the server gets a request for URL?word+word+word, it splits
> up the words, and calls
> URL.p word word word
> or
> word word word
> Nat

Thank you.
Ray Stell (703) 231-4109