[plug] Debian 2.1 slink

Anthony J. Breeds-Taurima tony at cantech.net.au
Thu May 13 18:04:04 WST 1999


On Thu, 13 May 1999, Trevor Phillips wrote:

> "Anthony J. Breeds-Taurima" wrote:
> > 
> > Just to be nit picky ..... BUT the point still remains that some pages should
> > be cacheable and therfore should avoid CGI "type" url's.  So that cache admin's
> > can do the right thing by everyone ....
> 
> Still, CGI's have their own way of stating a page should or shouldn't be
> cached (via HTTP/1.1). Why not rely on that? Or is the general
> assumption CGI writers don't know how to do that? ^_^

Yes they do ... and if these headers could be relied upon to be acturate this
would be a mote(sp?) point BUT ATM they can't be relied upon .... It's nit
that they don't know HOW to do it and infact losts of professional CGI
writers/ webmaster do use them correctly BUT they are still the minority .....
 
> > I'm sure you could hve one php/cgi/perl script that looks at it's "name and
> > sources an appropriate file.  You could the create a symlinkn to that file
> > with multiple names and get multiple content AND still cache the object ....
> 
> Nicer way is to have it as part of the path. eg;
> /bin/mycgi/afilename.html
> That'd access the CGI /bin/mycgi and set an Env var to afilename.html
> (Ummm, PATH_INFO from memory, but don't quote me on it).
> Or better still associate a CGI via an action/handler. ^_^

Both of thsese sound great ;) ... BUT the orginal point AFAICT was that LOTS
of site dish statice content from within "CGI" type url .... I wasn't trying
to say that CGI was bad should be avoided etc etc just that if you want to use
CGI as a means to document management try to hide it so that the pages can
will be cached ......

Yours Tony.



More information about the plug mailing list