Skip to main content.
home | support | download

Back to List Archive

RE: Re: Swish-E New Feature?

From: David Norris <kg9ae(at)>
Date: Sat Jan 23 1999 - 11:50:45 GMT
> Caching is an option, as long as the storage options
> are faster than a plain search. Let's say you store the
> results in a text file. How do you track it in the

Caching isn't worth the extra time and resources, in my mind, since a given
set of results may only be used once.  Reading a file from my Ultra-Wide
SCSI disks shouldn't be much, if any, faster than SWISH-E reading the index
file from disk again.  Caching to RAM isn't an option in many scripting
languages.  And, you could easily run out of RAM limiting the use of the

> all doing this at the same time? What if the client's
> cookies are disabled and you don't want to have someone
> altering parameters in URL's?

Two options come to mind;
1. Disable GET method on the script's URL in your HTTPD configuration file.

2. Destroy all variables passed via GET before the important part of the
script is run.  Use only those that have been POSTed or are from cookies.

With a recent version of Apache, I think 1.3.3 or higher, you can limit GET
data to minimize denial-of-service attacks.

Jason Birch came up with some paging buttons for my Simple Web Search script
that only use POST.  Surprisingly simple and not ugly at all.


Just my 2 cents, I think it would be nice to have some paging switches for
SWISH-E.  Especially, if it doesn't break anything in the current version.
If for no other reason than to have them.  I like the idea of GNU-style long
and short switches to maintain compatibility.  One thing that is important
to me, however, are the comment fields at the beginning of the output.  The
comments would have to remain for this feature to be of the most use.  At
least, my script would benefit from the paging switches if the comments
remain intact.  A few new comment 'key: value' that specify the offset and
maxhits would make it most efficient to implement in the script.

I think that I have a fairly speedy way around the lack of offset.  However,
I can't think of any reason it would hurt to add a few more commandline
switches.  Cluttered maybe, but, I don't see why that is a problem.

,David Norris

World Wide Web -
Page via mail -
ICQ Universal Internet Number - 412039
E-Mail -
Received on Sat Jan 23 03:49:33 1999