marc 98/07/12 20:23:39
Modified: . STATUS Log: It never snows in Seattle. Revision Changes Path 1.437 +24 -18 apache-1.3/STATUS Index: STATUS =================================================================== RCS file: /export/home/cvs/apache-1.3/STATUS,v retrieving revision 1.436 retrieving revision 1.437 diff -u -r1.436 -r1.437 --- STATUS 1998/07/13 03:19:38 1.436 +++ STATUS 1998/07/13 03:23:38 1.437 @@ -14,29 +14,18 @@ RELEASE SHOWSTOPPERS: - * Ralf: mod_so doesn't correctly initialise modules. For instance - the handlers of mod_perl are not initialised. - An ap_init_modules() could be done from mod_so but this is too much. + * auto_conf.h include order is wrong? needs to be _before_ os.h? - I've already debugged this up to ap_invoke_handler() and it correctly - sees the handlers from mod_perl ("perl-script") and actually runs them. - But under DSO situation it returns DECLINED while under non-DSO - situation it runs fine. Sure, its mod_perl's fault because its mod_perl - code which returns DECLINED. But it definitely seems to be caused by a - missing init in mod_so under DSO situation. I've already asked Doug for - hints but he has not had a chance to look into it. - - Currently at least mod_perl is broken under the DSO situation because of - this missing init in mod_so. But perhaps there are more modules which - have the same problem. This should be fixed for 1.3.1 or at least found - out why it is happening! +WIN32 1.3.1 RELEASE SHOWSTOPPERS: -WIN32 1.3 RELEASE SHOWSTOPPERS: - * Win95: when authentication is required for directory /foobar/, direct access to /foobar/bletch is permitted. PR #2145 + + UPDATE: may be false alarm, probably shouldn't hold 1.3.1. - UPDATE: may be false alarm, probably shouldn't hole 1.3.1. + * can not build tarball until someone verifies the final code + will build on win32. Want to avoid changes-after-tag that + happened with 1.3.0. Documentation that needs writing: @@ -104,6 +93,23 @@ CustomLog-like tailoring of directory listing formats Needs patch: + + * Ralf: mod_so doesn't correctly initialise modules. For instance + the handlers of mod_perl are not initialised. + An ap_init_modules() could be done from mod_so but this is too much. + + I've already debugged this up to ap_invoke_handler() and it correctly + sees the handlers from mod_perl ("perl-script") and actually runs them. + But under DSO situation it returns DECLINED while under non-DSO + situation it runs fine. Sure, its mod_perl's fault because its mod_perl + code which returns DECLINED. But it definitely seems to be caused by a + missing init in mod_so under DSO situation. I've already asked Doug for + hints but he has not had a chance to look into it. + + Currently at least mod_perl is broken under the DSO situation because of + this missing init in mod_so. But perhaps there are more modules which + have the same problem. This should be fixed for 1.3.1 or at least found + out why it is happening! * get_path_info bug; ap_get_remote_host should be ap_vformatter instead. See: <[EMAIL PROTECTED]>