In a hurry, so a quick note. In 3.2, mod_python.publisher was changed
to read:
if req.method!='HEAD':
# TODO : the problem is that a handler can still use
req.write
# and break the assumption that nothing should be written
with the
# HEAD method.
On 12/29/05, Garrett Rooney [EMAIL PROTECTED] wrote:
Here's a very lightly tested patch to allow mod_proxy_fcgi to deal
with fastcgi records with content length greater than AP_IOBUFSIZE.
If someone could double check the math to make sure it's correct in
all cases I'd appreciate it, I tested
On 12/29/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
[1] and [3] on their own are simply enough, [2] is the crazy part.
Does any of this make any sense?
I don't know enough about [2] to say if it's possible or not, but it
makes sense at first glance. I'm highly in favor of [3], since it
On 12/28/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 12/28/05, Fenlason, Josh [EMAIL PROTECTED] wrote:
I'm running into an issue where Apache 2.2.0 on AIX won't start if there is
more than one Listen directive.
Can you send me truss of startup using the failure configuration?
truss -o
Just this last one, and then that's it until mid-next-week :)
On Dec 29, 2005, at 5:47 PM, Colm MacCarthaigh wrote:
[1] and [3] on their own are simply enough, [2] is the crazy part.
Does any of this make any sense?
This all makes a lot of sense to me, in fact #2 kind of aligns
with
On Dec 21, 2005, at 12:34 PM, Justin Erenkrantz wrote:
--On December 21, 2005 11:11:11 AM +0100 Sander Temme
[EMAIL PROTECTED] wrote:
Yes, but is that reworked remark about FreeBSD threads cool with you?
Close, but not quite. Threads are enabled in APR by default on 5.4-
RELEASE and
Howdy,
While reviewing the make_child code in prefork.c, I came across the
RAISE_SIGSTOP macro. It looks like this macro allows you to utilize gdb to
attach at specific locations based on the value of raise_sigstop_flags. I
checked through the mailing list archives and saw that this code was
On 12/30/05, Garrett Rooney [EMAIL PROTECTED] wrote:
On 12/29/05, Garrett Rooney [EMAIL PROTECTED] wrote:
Here's a very lightly tested patch to allow mod_proxy_fcgi to deal
with fastcgi records with content length greater than AP_IOBUFSIZE.
If someone could double check the math to make
There's a small bug in the fastcgi header parsing code, the chars need
to be treated as unsigned in order for all the shifting to work
properly...
Log follows, patch attached.
-garrett
Fix the extraction of shorts from the header parsing code.
* modules/proxy/mod_proxy_fcgi.c
(dispatch):
I haven't been able to find the bug yet. As a next step, I'll try using
valgrind on a build with pool debugging enabled.
Brian
On Dec 4, 2005, at 11:14 PM, Paul Querna wrote:
I finally got around to upgrading to trunk w/ the Event MPM on one
of my
machines. Within a couple hours of
On Dec 30, 2005, at 5:51 PM, Brian Pane wrote:
I haven't been able to find the bug yet. As a next step, I'll try
using
valgrind on a build with pool debugging enabled.
On entry to allocator_free, if
(node == node-next node-index current_free_index)
is true, then the do { } while
On Dec 30, 2005, at 6:48 PM, Roy T. Fielding wrote:
On Dec 30, 2005, at 5:51 PM, Brian Pane wrote:
I haven't been able to find the bug yet. As a next step, I'll try
using
valgrind on a build with pool debugging enabled.
On entry to allocator_free, if
(node == node-next node-index
On Dec 4, 2005, at 11:14 PM, Paul Querna wrote:
I finally got around to upgrading to trunk w/ the Event MPM on one
of my
machines. Within a couple hours of starting it, I had a process
spinning, and consuming 100% CPU.
Backtrace from the spinning thread:
(gdb) thread 6
[Switching to thread
13 matches
Mail list logo
