Searches, problems with

• Mail folder: WWW Talk Jul-Oct 1993
• Next message: Edward Vielmetti: "Re: who determines formatting "
• Previous message: Nathan Torkington: "Searches, problems with"

Date: Wed, 7 Jul 1993 11:54:03 +1200
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Message-id: <199307062354.AA21761@kauri.vuw.ac.nz>
To: www-talk@nxoc01.cern.ch
Subject: Searches, problems with
Status: RO

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)
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).

DISCUSSION
----------

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
	URL.sh word word word

Nat