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]>
