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

[PW <sub...@me...>]

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

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

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?

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?*