Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
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? well, Apache::Registry started out as a mod_cgi emulation layer, trying to speed up legacy mod_cgi scripts without alteration. personally, I think that concept is flawed because we all know that many legacy CGI scripts are poorly written, so you need take special measure to not fall into the numerous documented Registry traps. not to mention that Registry doesn't handle HEAD requests properly (in 1.0), if you read POST data elsewhere you're SOL in your CGI script, etc. but, ok, say you have your CGI emulation layer - that's one facet of Registry. however, Registry also acts as a dispatch mechansim for people wanting to use the mod_perl API without writing separate handlers for each bit of functionality - since you get $r passed in automatically, or can retrieve it via Apache-request on your own, you are fully free to use Registry this way and many people do. fiddling with $r-status is _only_ possible when Registry is used in this way - there is no mod_cgi equivalent way to set that part of the request record (that I know about, anyway :) for people who want to use the mod_perl API to, say, return REDIRECT, there needs to be some mechanism to allow them to do so, and the $r-status hack has traditionally served this purpose. (one of) my points before was that with 2.0 and the Cooker idea, we really can (and ought to) have two versions of Registry to accomodate these two needs - people who just want faster mod_cgi (and Registry returns OK or SERVER_ERROR) and people who want the mod_perl API (and Registry returns the script return code). separating out the two classes of users will probably make the Registry logic much easier and cleaner. just my $0.02. --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) I don't see what's wrong with your change, it brings things to be more consistent with Registry.pm. I've modeled the RegistryCooker after PerlRun.pm/RegistryNG.pm, but referring to Registry.pm when unsure. In any case, let's leave 1.0 alone (those who need it changed, can subclass RegistryNG) and work out a good 2.0. Re: ModPerl::RegistryCooker and its subclasses, you have to come forward and send tests that don't work as expected and we will act accordingly. My goal is to have an exhaustive test suite for registry scripts, because I'm sick of running my in-head built-in mod_perl ;) That includes lots of edge cases, for various error cases and such. Currently we have 34 tests, but more are needed. 206ok 404ok 500ok basic..ok closureok perlrun_requireok redirect...ok special_blocks.ok All tests successful. Files=8, Tests=34, 11 wallclock secs ( 6.80 cusr + 0.80 csys = 7.60 CPU) __ Stas BekmanJAm_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
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. __ Stas BekmanJAm_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
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Stas Bekman wrote: Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. 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. 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?
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
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. 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? 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. 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 BekmanJAm_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
