DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32022.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
(though with proxy
issues on HEAD mod_rewrite [P] stuff is still completely broken).
yeah. if I have the time I'll try to track down exactly the revision that
caused this failure so it can also be added to showstoppers, if merely so
somebody takes the time to explicitly address it. not sure
William A. Rowe, Jr. wrote:
Someone cried wolf, b.t.w., about connection and request pool
allocation being too tightly coupled to threads. They can be
decoupled pretty painlessly, by tying an allocator to a single
connection object. We can presume that request pools will be
a subpool of each
Justin Erenkrantz wrote:
On Mon, Nov 01, 2004 at 08:39:47PM -0500, Greg Ames wrote:
This makes it behave properly on my laptop with speculative reads. I have
no idea if it works with mod_ssl or what speculative buys us.
mod_ssl will most likely work correctly without changes. -- justin
Let's
* Joe Orton [EMAIL PROTECTED] wrote:
http://lists.netsys.com/pipermail/full-disclosure/2004-November/028248.html
describes a memory consumption DoS against 2.0, which has been assigned
CVE CAN-2004-0942; in the case given, ap_rgetline_core will allocate
approx N * 3 bytes to hold the line,
I took a quick look at this patch and it seems to work well as long
as all of the listed attributes are OR'ed together. I don't have a good
suggestion yet, but is there a way to implement the logic so that
attributes could be also AND'ed together? Or even a NOT-EQUAL
operation?
Brad
[EMAIL
Thats a tricky one.. We could introduce a new directive
AuthLDAPRequireAll on|off that would control this behavior.
I'm open to other ideas too..
-Ryan
On Nov 2, 2004, at 5:19 PM, Brad Nicholes wrote:
I took a quick look at this patch and it seems to work well as long
as all of the listed
