[+1] Release 2.2.32 as legacy GA
Built RPMs on RHEL6 using my own spec file, derived from Red Hat's.
Appears to run fine on x86_64.
Non-binding etc.
--
Bojan
Stefan Fritsch s...@sfritsch.de wrote:
Fixed, thanks.
Thanks.
--
Bojan
On Tue, 2012-06-19 at 15:42 +1000, Bojan Smojver wrote:
Docs contain this note for LimitRequestFieldSize directive:
noteUnder normal conditions, the value should not be changed from
the default. Also, you can't set this higher than 8190 without
modifying the source code
On Tue, 2010-11-02 at 23:16 -0400, Paul Lockaby wrote:
However, I do not know how to fix it. Has anyone else determined how
to solve this problem? Are there plans to update libapreq2 to address
this change in Fedora?
You may to try look at these:
On Wed, 2009-11-11 at 13:09 +0200, Graham Leggett wrote:
Apache httpd does lots of things right.
We must resist the temptation to throw out what we do right, while we
try move forward fixing what we do wrong.
And there is also a reason why Google's Chome is essentially (pre)fork.
This model
On Thu, 2009-11-05 at 13:38 +0200, Graham Leggett wrote:
I'm keen to teach httpd v3.0 to work asynchronously throughout - still
maintaining the prefork behaviour as a sensible default[1], but being
asynchronous and non blocking throughout.
[1] The fact that dodgy module code can leak, crash
On Fri, 2009-10-16 at 08:00 +1100, Bojan Smojver wrote:
While playing with slowloris against prefork, I wrote the attached
craziness.
On the back of the bug #48094, I reworked the latest version of this
craziness, which now suspends worker threads before shutting down the
sockets. Just in case
On Sat, 2009-10-31 at 13:14 +1100, Bojan Smojver wrote:
Actually, we can just reuse WORKER_SIGNAL for all this.
And even simpler.
--
Bojan
--- httpd-2.2.14-v/server/mpm/worker/worker.c 2007-07-18 00:48:25.0 +1000
+++ httpd-2.2.14/server/mpm/worker/worker.c 2009-10-31 22:59:37.566221296
On Sat, 2009-10-31 at 23:00 +1100, Bojan Smojver wrote:
+/* wait to resume */
+while (suspend_workers) {
+apr_sleep(SCOREBOARD_MAINTENANCE_INTERVAL / 10);
+}
Er, that should be:
+/* suspend and then wait to resume */
+if (suspend_workers) {
+worker_data[i
On Fri, 2009-10-30 at 14:59 +1100, Bojan Smojver wrote:
Of course, SIGINT plucked out of thin air.
Actually, we can just reuse WORKER_SIGNAL for all this.
--
Bojan
--- httpd-2.2.14-v/server/mpm/worker/worker.c 2007-07-18 00:48:25.0 +1000
+++ httpd-2.2.14/server/mpm/worker/worker.c 2009
On Fri, 2009-10-23 at 10:12 +1100, Bojan Smojver wrote:
Slower, but safer attached (not even compiled, so could be utterly
bogus).
BTW, this approach still isn't safe. The socket can disappear (i.e. be
closed) between the test and the closing (or shutdown()). Worse, with
shutdown(), we could
On Fri, 2009-10-30 at 13:07 +1100, Bojan Smojver wrote:
Workable?
Something like the attached. This compiles and kinda does something, but
it has not been extensively tested. Of course, SIGINT plucked out of
thin air.
--
Bojan
--- httpd-2.2.14-v/server/mpm/worker/worker.c 2007-07-18 00:48
On Fri, 2009-10-30 at 14:59 +1100, Bojan Smojver wrote:
+apr_os_sock_get((apr_os_sock_t *)csd,
worker_data[i].socket);
+if (csd != -1) {
+shutdown(csd, SHUT_RDWR);
BTW, there is a possibility of a race condition above. Slight, but still
there.
In APR
On Thu, 2009-10-22 at 07:54 -0400, Jeff Trawick wrote:
I have long suspected that there is a race here, and that this code
should do shutdown for read and write rather than close in order to
avoid any possible funny business with descriptors.
Phew! So I'm not totally insane after all :-)
Note
On Fri, 2009-10-23 at 07:58 +1100, Bojan Smojver wrote:
+apr_os_sock_get((apr_os_sock_t *)csd, worker_sockets[j]);
He, he... Cut'n'paste eh? It's not [j], it's [i], of course :-)
--
Bojan
On Fri, 2009-10-23 at 07:58 +1100, Bojan Smojver wrote:
Note that the attached _still_ has a race.
Slower, but safer attached (not even compiled, so could be utterly
bogus).
--
Bojan
Index: server/mpm/worker/worker.c
On Fri, 2009-10-23 at 10:12 +1100, Bojan Smojver wrote:
int i;
AIEE! Missing csd declaration above.
--
Bojan
On Wed, 2009-10-21 at 09:43 +1100, Bojan Smojver wrote:
Probably something to do with me
closing wrong sockets - didn't have time to check in detail.
Actually, calling close() is the wrong thing to do. Calling shutdown()
is the go.
--
Bojan
On Wed, 2009-10-21 at 19:17 +1100, Bojan Smojver wrote:
Actually, calling close() is the wrong thing to do. Calling shutdown()
is the go.
This is what I mean.
--
Bojan
--- httpd-2.2.14-v/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14/server/mpm/prefork
On Mon, 2009-10-19 at 09:22 +1100, Bojan Smojver wrote:
and I haven't touched worker at all
Here is another take on the whole thing, this time worker included. In
my tests, prefork performed a lot better with this approach. Worker
tended to remain under DoS more and would also disconnect far
On Fri, 2009-10-16 at 08:00 +1100, Bojan Smojver wrote:
While playing with slowloris against prefork, I wrote the attached
craziness.
Here is another take on the problem, call it Craziness 2.0.
The idea here is that a busy server is highly unlikely to be stuck
reading using all its children
On Sun, 2009-10-18 at 10:37 +0200, Stefan Fritsch wrote:
An attacker can easily circumvent this by opening one connection that
slowly downloads a large file. Checking for a certain percentage of
all children would be better.
Yeah, I was thinking of that too - just wanted to err on the side
On Sun, 2009-10-18 at 19:48 +1100, Bojan Smojver wrote:
We can also create a checksum of pids/states and if this is the same
second time around, pronounce it under attack
Like this.
--
Bojan
--- httpd-2.2.14-v/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14
On Sun, 2009-10-18 at 21:56 +1100, Bojan Smojver wrote:
Like this.
Ah, details, details...
--
Bojan
--- httpd-2.2.14-v/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14/server/mpm/prefork/prefork.c 2009-10-18 23:42:13.831280800 +1100
@@ -48,6 +48,7 @@
#include
On Sun, 2009-10-18 at 23:46 +1100, Bojan Smojver wrote:
+/* If after one maintenace interval we still see the same
+ * situation on the scoreboard, close 10% of client
sockets.
The percentage picked out of thin air, of course.
--
Bojan
On Sun, 2009-10-18 at 21:56 +1100, Bojan Smojver wrote:
Like this.
Here is a more aggressive variant, which disconnects all sockets in read
state and at least 10% of all sockets when we get in trouble. On my test
machine, it is quite effective against slowloris.
General idea
On Mon, 2009-10-19 at 00:00 +0200, Stefan Fritsch wrote:
Randomly killing possibly legitimate connections is some kind of DoS,
too.
For sure. Anything we do, including reducing connection timeout on a
heavily loaded server is DoS. We just pick the type of DoS we want,
instead of the one
On Mon, 2009-10-19 at 09:22 +1100, Bojan Smojver wrote:
that SIGINT is a poke in the eye
Maybe we could use SIGURG here. After all we do have an urgent message
for the socket :-)
--
Bojan
On Mon, 2009-10-19 at 10:40 +1100, Bojan Smojver wrote:
Maybe we could use SIGURG here. After all we do have an urgent message
for the socket :-)
Hmm, it's a real bummer we don't have more user defined signals. We
could reach for RT stuff, but I'm not sure how portable that is.
Anyhow, here
On Mon, 2009-10-19 at 12:27 +1100, Bojan Smojver wrote:
+#ifndef NO_USE_SIGACTION
+static void close_client_socket(int sig, siginfo_t *info, void
*context)
+#else
+static void close_client_socket(int sig)
+#endif
+{
+if (client_socket != -1) {
+#ifndef NO_USE_SIGACTION
While playing with slowloris against prefork, I wrote the attached
craziness.
I had httpd under slowloris attack (which would normally completely DOS
the server) and it seems that the attached patch made it handle the
requests. Sure, there was a lot of carnage in the process (child
processes
On Fri, 2009-10-16 at 08:00 +1100, Bojan Smojver wrote:
+ap_mpm_safe_kill(reader, SIGKILL);
Actually, this can be SIGTERM too. Still does the job.
--
Bojan
On Fri, 2009-10-16 at 08:00 +1100, Bojan Smojver wrote:
I wrote the attached craziness.
Slightly more sophisticated craziness attached.
--
Bojan
--- httpd-2.2.14/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14-p/server/mpm/prefork/prefork.c 2009-10-16 12:19
On Fri, 2009-10-16 at 12:31 +1100, Bojan Smojver wrote:
Slightly more sophisticated craziness attached.
OK, just a little bit cleaner this time.
--
Bojan
--- httpd-2.2.14/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14-p/server/mpm/prefork/prefork.c 2009-10-16
On Tue, 2009-09-01 at 00:43 +0200, Stefan Fritsch wrote:
It is implemented as
an input connection filter that sets the socket timeout so that the
total request time does not exceed the timeout value.
Nicely done. It's really do you business efficiently or get out of the
way kind of thing.
On Thu, 2009-07-23 at 18:40 -0700, Mark Hedges wrote:
Argh why do they try to backport bugfixes to three-year
old Apache 2.2.3 instead of using current stable minor
revision 2.2.11? *tears out hair*
Better question: why is RHEL6 not out yet ;-)
--
Bojan
On Wed, 2009-07-22 at 11:35 +0300, Mihai Moldovanu wrote:
+ ./testall -v -q
What happens when you run make check from the build directory?
PS. If you look inside test/Makefile, you'll see that LD_LIBRARY_PATH is
adjusted before running the tests, in order to pick up now dynamically
linked DBM
On Wed, 2009-07-08 at 11:01 +1000, Bojan Smojver wrote:
So, the loop would be:
- poll()
- try assembling a full request from data read so far
- process if successful
- go back to poll() if not
Too naive?
I see that we'd most likely get stuck with the accept mutex (i.e. if
another
On Wed, 2009-07-08 at 22:53 -0400, Paul Querna wrote:
But the event mpm doesn't have an accept mutex :D
Yeah, I know. I was talking about making prefork async too.
--
Bojan
On Tue, 2009-07-07 at 16:01 +0200, Graham Leggett wrote:
As is httpd prefork :)
Yeah, definitely my favourite MPM :-)
As far as I understand this, the deal is that we need to have a complete
request before we start processing it. Otherwise, we can get stuck and
one of our precious resources is
Just wondering, if it would be useful to have a LimitRequestRate
configuration directive, which would then mitigate against Slowloris and
friends?
For instance, if Timeout is 5 seconds, Slowloris will push 8 bytes
through the pipe every 5 seconds (X-a: b\r\n), giving it the rate of 1.6
bytes per
On Tue, 2009-06-09 at 09:19 +0100, mmm zzz wrote:
gcc: +b: No such file or directory
From memory, +b may be an option used by HP-UX specific linker, so maybe
GCC gets confused and sees it as a file. Don't have a box to try any
more... Maybe you need to give it -Wl,+b instead?
--
Bojan
On Tue, 2009-06-09 at 10:44 +0100, mmm zzz wrote:
I'm just a newbie in the compilation and don't know a lot in the
compilers options and can't deside what to add or to remove to be able
to finish the compilation in HP with GCC or CC.
I'm guessing you'll need to have a good GCC installed (when
On Fri, 2009-03-06 at 11:35 -0800, Joe Schaefer wrote:
Please test and vote on
http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz
http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz.asc
Compiles and runs all tests successfully on F-10.
--
Bojan
On Sat, 2009-03-07 at 10:34 +1100, Bojan Smojver wrote:
On Fri, 2009-03-06 at 15:25 -0800, Joe Schaefer wrote:
Is that a +1 to release, or not yet?
I'll try to build some RPMs from it first and report back.
+1.
Builds OK as RPM on F-10 and F-11.
--
Bojan
On Tue, 2009-02-17 at 08:47 +0200, Issac Goldstand wrote:
I'm all
for calling 2.11 a dud and restarting with 2.12
Version numbers are cheap - go for it.
--
Bojan
On Thu, 2009-01-29 at 14:53 -0500, Philip M. Gollucci wrote:
I built from SVN or do you mean you'll add a patch to the rpm
after release ?
I thought you were referring to current RPM build/install there.
If there is a problem with build/install on CentOS from source and we
know how to fix
On Thu, 2009-01-29 at 13:53 -0800, Joe Schaefer wrote:
That is bunk. We shoul NEVER try to support svn builds for releases,
because that makes us dependent on whatever autocruft is on CentOS.
It also doesn't help diddly squat when testing a potential candidate
for release, since those are
On Thu, 2009-01-22 at 16:50 +0200, Issac Goldstand wrote:
I don't get any fails by me... Can you try make test-ing apreq2-2.08
and see if you get the same fails so we know if it's a regression?
Will do.
--
Bojan
On Mon, 2009-01-19 at 23:06 -0500, Philip M. Gollucci wrote:
If not, I'm tempted to roll it tomorrow day-time unless someone else beats me
to it.
Go ahead and roll. If you don't make it, I'll jump in later in the week.
--
Bojan
On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote:
Are you planning to pursue 2.10 as RM or
should we be moving on to 2.11? The only outstanding issue I am aware
of is pgollucci's claim that the perl modules aren't linking correctly
to libapreq2 on Solaris. While that would be nice to
On Mon, 2009-01-12 at 18:44 +0200, Issac Goldstand wrote:
Regardless of that, I'd like to merge in the enhanced-cgi stuff later in
the week. So we can either do 2 consecutive releases or get 2.10 out
the door now and re-vote on 2.11 in another week or so.
We didn't have a release for a
On Thu, 2008-11-27 at 01:40 -0500, Philip M. Gollucci wrote:
Committed revision 721096.
Backported to branches/2_10 721099.
Let me know when you backport all the stuff you wanted to get from the
trunk and I'll roll RC2.
--
Bojan
On Wed, 2008-11-19 at 04:34 -0500, Philip M. Gollucci wrote:
its 4:30am and I've not look at this code in a while, the debugging will
have to wait.
Also, I I'm pretty sure I want to merge 1-2 things from trunk to 2.10
that are low risk but important.
Cool. That's why we have RCs after
On Fri, 2008-11-14 at 09:10 -0500, Adam Prime wrote:
I was reminded of a documentation omission by an email on the mod_perl
list this morning. Can something be added into the porting warnings here:
http://httpd.apache.org/apreq/docs/libapreq2/group__apreq__xs__request.html
mentioning
On Tue, 2008-11-11 at 17:00 +1100, Bojan Smojver wrote:
OOPS, sorry.
The trunk has been reverted to version 2.10 for now.
--
Bojan
On Mon, 2008-11-10 at 22:56 -0500, Philip M. Gollucci wrote:
Probably a good thing, I'm not sure what the differences are.
[are all my solaris fixes on the 2_10 branch ?]
Here you go...
--
Bojan
diff -rauN --exclude=.svn apreq-2.10/CHANGES apreq/CHANGES
--- apreq-2.10/CHANGES 2008-11-11
On Wed, 2008-11-12 at 10:36 +1100, Bojan Smojver wrote:
We should find out what's going on with this before the release.
What I've discovered so far is that mod_apreq_output_filter_test.c gets
the correctly parsed content from apreq machinery and puts all that in
the brigade. But, upon
On Wed, 2008-11-12 at 20:31 +1100, Bojan Smojver wrote:
This will require further debugging...
After employing mod_dumpio, it seems that Apache actually outputs
everything out, even over SSL. I have no idea how and why it doesn't
show up in the client (i.e. as reported by request.t). Maybe
On Wed, 2008-11-12 at 23:08 -0500, Philip M. Gollucci wrote:
Apache-Test definitely jumps through hoops for SSL.
Are your perl SSL CPANs up-to-date ?
Whatever Fedora 9 has, I have. Whether that's most up to date, I don't
know.
I think I should just put out an RC tarball and let people test.
It has been over two years since the latest apreq2 release, so it is
time to get some new code out the door. Numerous bugs were fixed (see
the full list in the CHANGES file) since the last official release
(2.08), so please give us feedback on this release candidate.
You can get the tarball, its
On Thu, 2008-11-13 at 17:29 +1100, Bojan Smojver wrote:
It has been over two years since the latest apreq2 release, so it is
time to get some new code out the door. Numerous bugs were fixed (see
the full list in the CHANGES file) since the last official release
(2.08), so please give us
On Thu, 2008-11-13 at 02:01 -0500, Philip M. Gollucci wrote:
(ahh, you were in unix group httpd, I've just added you)
I am not an httpd committer. I only have commit rights to apreq
directory.
--
Bojan
On Tue, 2008-11-11 at 18:41 +1100, Bojan Smojver wrote:
BTW, 2.08 and 2.09-rc2 fail exactly the same on my box. Something must
be screwed in my setup...
When I run the tests against vanilla httpd (instead of Fedora supplied
one), the number of tests drops to 82 (as opposed to 121 with Fedora
On Wed, 2008-11-12 at 09:38 +1100, Bojan Smojver wrote:
These two tests fail when SSL is enabled.
Indeed, things get chopped off. I'm attaching an example from test 34.
The files 1.e and 1.r are expected/received content, respectively, that
the test sees over regular HTTP. The files 2.e and 2.r
On Tue, 2008-11-11 at 18:41 +1100, Bojan Smojver wrote:
BTW, 2.08 and 2.09-rc2 fail exactly the same on my box. Something must
be screwed in my setup...
Given that these failures are quite obviously not regressions, I'm
inclined to put an RC tarball out there for people to test.
--
Bojan
On Tue, 2008-11-11 at 20:02 +1100, Bojan Smojver wrote:
When I run the tests against vanilla httpd (instead of Fedora supplied
one), the number of tests drops to 82 (as opposed to 121 with Fedora
supplied httpd) and all those pass. So, there must be some functionality
that I didn't compile
On Mon, 2008-11-10 at 22:45 -0500, Philip M. Gollucci wrote:
did you see the [EMAIL PROTECTED] post ?
No, not really. I don't normally follow that list, as my Perl really,
really sucks (did I mention my Perl really sucks? ;-)).
If you want to volunteer RM for one of them, I'll take the
On Mon, 2008-11-10 at 23:46 -0500, Philip M. Gollucci wrote:
Is that with
$ make test TEST_VERBOSE=1
Fails in exactly the same way as make release_test.
--
Bojan
On Tue, 2008-11-11 at 07:51 +0200, Issac Goldstand wrote:
Whoa
-0.9
Update release info *after* the RCs pass muster. The release only
happens after the votes - I'm pretty sure that that's in the RELEASE
file (otherwise 1.34 would have a release date of 2006 ;-p)
OOPS, sorry.
--
Bojan
On Tue, 2008-11-11 at 08:02 +0200, Issac Goldstand wrote:
I'm gonna play with my version too. I'll shout if I get something
working (and you do the same?)
OK.
--
Bojan
On Tue, 2008-11-11 at 15:54 +1100, Bojan Smojver wrote:
On Mon, 2008-11-10 at 23:46 -0500, Philip M. Gollucci wrote:
Is that with
$ make test TEST_VERBOSE=1
Fails in exactly the same way as make release_test.
BTW, 2.08 and 2.09-rc2 fail exactly the same on my box. Something must
On Fri, 2008-07-11 at 18:46 +0300, Eli Marmor wrote:
DON'T FORGET TO MERGE THE ENHANCED-CGI !!!
Do you have a link?
--
Bojan
Is there anything that needs to be addressed still before we roll this?
It's been a long time since the last stable release, I think we should
go ahead and get something out the door...
--
Bojan
On Wed, 2008-06-04 at 21:35 -0700, Joe Schaefer wrote:
Needs a comment in the source about why we're using
volatile here, but otherwise +1.
Done on both the trunk and v2_10 branch.
Any comment regarding my other patch about strict aliasing warnings?
--
Bojan
On Thu, 2008-06-05 at 12:10 +1000, Bojan Smojver wrote:
I'm getting warnings about strict aliasing from GCC 4.3.0 and the
attached patch helped.
Committed to trunk and v2_10.
--
Bojan
I propose we fix this as attached. I tested this on Fedora 9 and it
works OK. Opinions?
--
Bojan
Index: library/parser_multipart.c
===
--- library/parser_multipart.c (revision 663420)
+++ library/parser_multipart.c (working copy)
@@
On Wed, 2008-06-04 at 21:35 -0700, Joe Schaefer wrote:
Needs a comment in the source about why we're using
volatile here, but otherwise +1.
Ah, yes... Sorry. I also need to fix up the comment in the CHANGES file.
--
Bojan
On Wed, 2008-05-07 at 11:20 -0400, Zero Altitude wrote:
The segfault appears to be due to handle having an illegal-to-read
memory address by the time its module member is referenced. I do not
appear to be doing anything untoward with respect to initializing
apreq, and so my current,
On Thu, 2008-05-08 at 02:16 -0400, Zero Altitude wrote:
I apologize: can you clarify the watchpoint suggestion? If you mean
while running the program as in, while apache is still running and
not crashed, this is virtually impossible -- as I said, the segfault
occurs only once in a few
On Tue, 2008-03-25 at 12:50 -0400, greg boyington wrote:
I hope this is a foolish question. When I check out the current
libapreq2 via svn, I don't get a configure script:
Run ./buildconf.
--
Bojan
On Fri, 2008-03-07 at 12:22 -0700, Chris Dukes wrote:
Your test is including the '-c', allowing it to pass.
OK. After I sent the patch, I realised that you toolchain only had a
problem with the whole thing during the link phase. Sorry :-(
Can you try replacing AC_COMPILE_IFELSE in my patch
On Fri, 2008-02-29 at 12:54 -0500, Chris Dukes wrote:
xlc_r -qcpluscmt
Yeah, we should only use -fno-strict-aliasing with GCC.
--
Bojan
On Mon, 2008-03-03 at 09:03 +1100, Bojan Smojver wrote:
Yeah, we should only use -fno-strict-aliasing with GCC.
Can you let me know if this helps? You'll need to run buildconf, of
course...
--
Bojan
Index: acinclude.m4
As the maintainer of libapreq2 for Fedora, I had to do a bit of
pkgconfig hacking recently on current libapreq2 (2.09-rc2) in order to
get it to be multilib compliant.
You can see that work here:
http://cvs.fedoraproject.org/viewcvs/rpms/libapreq2/devel/
The files in question are
On Fri, 2007-10-05 at 15:37 +1000, Bojan Smojver wrote:
- make conn-pool have/own its own allocator
- destroy, rather then clear conn-pool on connection close
Example patch attached.
--
Bojan
--- httpd-2.2.6/server/core.c 2007-08-07 22:12:20.0 +1000
+++ httpd-2.2.6-patched/server
On Fri, 2007-10-05 at 16:06 +1000, Bojan Smojver wrote:
Example patch attached.
Sorry, that patch is seriously brain dead. I'll try modifying the
prefork.c instead, which seems like a better place to do it.
Keep you posted...
--
Bojan
On Fri, 2007-10-05 at 15:37 +1000, Bojan Smojver wrote:
I noticed that if a large number of buckets in a brigade are sent out,
the resident memory footprint of httpd process (been playing with 2.2.6
for now) will go up significantly.
I didn't mention this before, but MaxMemFree directive
On Fri, 2007-10-05 at 16:56 +1000, Bojan Smojver wrote:
Keep you posted...
Another approach attached.
--
Bojan
--- server/mpm/prefork/prefork.c 2007-10-05 17:27:13.0 +1000
+++ server/mpm/prefork/prefork.c.patched 2007-10-05 17:14:25.0 +1000
@@ -465,7 +465,7 @@
static void
Quoting Aleksey Midenkov [EMAIL PROTECTED]:
And what if a large file is downloaded and processed by filters? Did the
buckets allocated by filters will not be deallocated until the connection
end? This can be a cause of DOS. The buckets should be freed after they have
flushed out of
Quoting Joe Orton [EMAIL PROTECTED]:
It sounds like that is the root cause. If you create a brigade with N
buckets in for arbitrary values of N, expect maximum memory consumption
to be O(N). The output filtering guide touches on this:
I noticed that if a large number of buckets in a brigade are sent out,
the resident memory footprint of httpd process (been playing with 2.2.6
for now) will go up significantly.
For instance, one could replicate this behaviour by having a file
processed by the INCLUDES filter, which contains a
Are we going to have 2.09 release? It's been quite some time since RC2
went out...
--
Bojan
On Thu, 2007-05-10 at 10:02 -0700, Chris Darroch wrote:
I apologize for joining this thread a little late. I know it's
more complicated, but I'm inclined to suggest trying to bring the more
comprehensive trunk fixes into 2.2.x.
Just a ping on the status of this backport...
--
Bojan
On Thu, 2007-05-10 at 08:20 +0200, Plüm, Rüdiger, VF-Group wrote:
As far as I understand your problem description the bug is only in 2.2.x and
not in
trunk. So could you please give a pointer to the revision(s) in trunk that
fixed this?
This can be considered for backport then. If this is
On Thu, 2007-05-10 at 17:01 +1000, Bojan Smojver wrote:
I don't think this applies to trunk. The trunk uses configuration groups
and then applies dbd_setup to all of them.
Looks like r503931 was where those configuration groups were introduced.
This was the text associated with the commit
On Thu, 2007-05-10 at 10:02 -0700, Chris Darroch wrote:
I apologize for joining this thread a little late. I know it's
more complicated, but I'm inclined to suggest trying to bring the more
comprehensive trunk fixes into 2.2.x.
If mod_dbd.c from trunk works in 2.2.x, we should just have
This should fix getting stuff from dbd_prepared_defns. It is against
2.2.x branch.
--
Bojan
Index: modules/database/mod_dbd.c
===
--- modules/database/mod_dbd.c (revision 536728)
+++ modules/database/mod_dbd.c (working copy)
@@
The problem is that the current 2.2.x code calls dbd_setup() only for
global server, therefore causing all other VHs to have things
uninitialised. If DBDPersist is On and dbd_setup_lock() is attempted,
mutex doesn't exist (it was never set up), so this fails. This patch
should fix all that (or so
On Wed, 2007-01-31 at 11:46 +1100, Bojan Smojver wrote:
---
if ($saw =~ /^(\d+)(\.(\d+))$/ and $version =~ /^(\d+)(\.(\d+))$/) {
---
Committed to trunk, revision 504716.
--
Bojan
1 - 100 of 269 matches
Mail list logo
