David Dick wrote: [...]
The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content.Personally I don't see how is it possible to accomodate everybody in the same handler. Because the requirements are conficting and second guessing is working in 99% but breaks for 1%, causing torn out hairs.
The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says;
If the developer just does straight out weird stuff and messes with $r->status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me?
Perhaps having two different sub-classes which do things differently is the right way to go. The default should follow the course of the least surprise and accomplish what it was designed for in first place: emulate mod_cgi, while giving the speed benefits. The other sub-class should pitch towards developers that use registry, for scripts which are expected to behave differently from mod_cgi.
Looks like that's what we have under mod_perl 1.0. Apache::Registry and Apache::PerlRun/RegistryNG behave differently and one should choose between the two according to their needs. Even though the overall implementation is different for a different reason (make a sub-classable registry).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
