I'm gonna puke if I see another connection-oriented error message with
no client IP.
Am I missing something basic, or is there really no reason NOT to have
ap_log_cerror()? It seems so obvious.
before:
[Fri Oct 29 06:56:16 2004] [info] (32)Broken pipe: core_output_filter:
writing data to the
On Fri, Oct 29, 2004 at 07:07:39AM -0400, Jeff Trawick wrote:
I'm gonna puke if I see another connection-oriented error message with
no client IP.
Am I missing something basic, or is there really no reason NOT to have
ap_log_cerror()? It seems so obvious.
+1, several times I've wanted one
On Fri, 29 Oct 2004, Joe Orton wrote:
+1, several times I've wanted one of those too.
+1 again. Looks like the fix mod_diagnostics and mod_filter's trace
have needed all the time:-)
--
Nick Kew
Jeff Trawick wrote:
I'm gonna puke if I see another connection-oriented error message with
no client IP.
Am I missing something basic, or is there really no reason NOT to have
ap_log_cerror()? It seems so obvious.
before:
[Fri Oct 29 06:56:16 2004] [info] (32)Broken pipe: core_output_filter:
I see your point about the req structure being tied to closely to
authentication phase so that authorization will not work without it.
Now I understand the need for util_ldap_cache_getuserdn() which is the
real patch that needs to be added. In other words, the relevant bug is
actually 28253
Since the checkuserid cache does not allow NULL or blank passwords
today and its purpose is for authentication, I'm just not completely
comfortable allowing another function whose purpose it is to simply
lookup user DN's to insert NULL or blank password entries. It seems
like it would
Win32-folk,
I'm migrating all my own work from InstallShield Windows Installer
and Multiplatform to the singular InstallShield X product. It too
creates .msi installers, and Java-based multiplatform installers,
and seems to be very good at grokking older installer projects,
although with
