Re: [Speedycgi-users] SpeedyCGI for non-CGI programs

[Sam H. <sa...@da...>]

 > Neither was I aware that SpeedyCGI supports this feature. A slightly
 > more extensive documentation would really be great, if your time
 > permits. My wish list:
 > 
 > - Additional information regarding the Group feature 
 >   (i.e. what defines a Group name or user? Apache's "nogroup" for example?)
 > - How would you declare a main CGI application and its associated
 > modules as a Group?
 > - Examples of Group configuration strategies and associated benefits
 > - Configuration examples to pass in mod_speedycgi environment variables

 OK, I'll try to do this.

 > Another question, yesterday I observed a weird behaviour with SpeedyCGI:
 > an environment variable from a static CGI program not running under
 > SpeedyPerl (also hosted under a different domain/IP) managed to slip
 > into the environment of a persistent SpeedyCGI application. Is this
 > possible? Here is some info:
 > 
 > Access log entry for a confused remote robot sending a request to host
 > "megapublic.de" for the page "http://www.ebay.com/" (each access
 > triggers a local static SSI-CGI program (the non-SpeedyPerl one, named clicktracer.cgi)):
 > 
 > p5082fb38.dip.t-dialin.net - - [22/Jun/2002:23:39:49 +0200] "GET
 > http://www.ebay.com/ HTTP/1.1" 200 16575 "-" "Mozilla/4.0 (compatible;
 > MSIE 4.01; Windows 95)" "p5082fb38.dip.t-dialin.net.219521024781986427" 3

 Is this the log entry for the first access?

 > Somehow the variable ENV{REQUEST_URI} containing "http://www.ebay.com/"
 > managed to push itself into the %ENV of a SpeedyPerl application named
 > clicktracer.scgi and running persistently on a different domain, "megapublic.com".
 > 
 > Pretty weird, no?

 Could be a bug in the module.  Is it reproducable?

 > As for the second name, SpeedyPerl sounds ok.
 > 
 > Thanks!
 > 
 > Philippe Wiede
 > Megapublic Inc. 
 > www.megapublic.com
 > ClickTracer [tm]
 > 
 > 
 > Sam Horrocks wrote:
 > > 
 > > Speedy has always supported non-CGI persistent perl programs as sort
 > > of secondary development goal.  It's never been at the forefront until
 > > recently.  But, for example, the exit-status code that's coming in 2.20
 > > was written purely for non-CGI programs - only non-CGI programs would
 > > care about that feature.
 > > 
 > > I don't think I've communicated the non-CGI capabilites of SpeedyCGI
 > > very well.  For example, Matt Sargeant released a program called "pperl"
 > > because he couldn't get speedy to compile on his box, and wasn't sure if
 > > it did non-CGI in the first place.  If pperl works for people, that's
 > > great, but I'm guessing that people would like to know that SpeedyCGI
 > > is also an option in case pperl can't do everything they want.
 > > 
 > > I'm planning to change the documentation to make it a little more clear
 > > that Speedy works with non-CGI programs.  Also, I think it might be a good
 > > idea to petition the CPAN maintainers for a second name for SpeedyCGI -
 > > SpeedyPerl seems logical.  Any opinions?*
 > 
 > 
 > -------------------------------------------------------
 > Sponsored by:
 > ThinkGeek at http://www.ThinkGeek.com/
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users