William A. Rowe, Jr. wrote:
At 04:48 PM 5/2/2005, Paul Querna wrote:
Personally, I have held off on starting refactors of code, because I do
not want to be detrimental to the ability to make a 2.2 Branch.
I would like to investigate making more parts of httpd async, in
conjunction with the
William A. Rowe, Jr. wrote:
This has somewhat turned into the real question, What are the show
stoppers for a 2.2 GA Branch?
If you believe an issue is a show stopper for a GA Branch, please add it
to the STATUS File.
So to amend your original proposal; on May 13;
* tagging an alpha
Hi...
I'm still fighting (probably for a lost cause.. but my boss ask me to
do this).
In the socket activity there are some troubles dealing with timeouts.
It is pretty easy to Anyone DoS any apache webserver.
I want to propose implementing a request timeout time, or at least a
check for
At 03:24 AM 5/3/2005, Paul Querna wrote:
William A. Rowe, Jr. wrote:
This has somewhat turned into the real question, What are the show
stoppers for a 2.2 GA Branch?
If you believe an issue is a show stopper for a GA Branch, please add it
to the STATUS File.
So to amend your original proposal;
Stephane Bailliez wrote:
Hi,
I'm facing an annoying issue during a PKI deployment and integration
within an organization.
The CA is created with the authority key identifier set as a critical
extension.
OpenSSL (including 0.9.7g) chokes (voluntarily) on critical extensions
and as a default
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
-Rasmus
Ivan Barrera A. wrote:
Hi...
I'm still fighting (probably for a lost cause.. but my boss ask me to
do this).
In the socket activity there are some troubles
- Original Message -
From: Paul Querna [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Tuesday, May 03, 2005 12:24 PM
Subject: Re: [PROPOSAL] Branch 2.1.x on May 13
William A. Rowe, Jr. wrote:
This has somewhat turned into the real question, What are the show
stoppers for a 2.2 GA
It doesn't.
Rasmus Lerdorf wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
-Rasmus
Ivan Barrera A. wrote:
Hi...
I'm still fighting (probably for a lost cause.. but my boss ask me to
do this).
Ivan Barrera A. wrote:
It doesn't.
How so? With accept filtering, simply opening up the socket doesn't
trigger Apache in any way, so how is Apache DoS'ed in that case? And
under FreeBSD with the httpready filter you can trickle really slow
requests over the socket and Apache still won't see
Ivan Barrera A. wrote:
It doesn't.
How does accept filtering not 'fix' this? If the http accept filter
enabled on FreeBSD, Apache will never even see those bogus requests.
Rasmus Lerdorf wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a
http://people.apache.org/~gregames/thread_create_recovery.patch
design:
* exit with APEXIT_CHILDSICK for thread create failures (same as other patches)
* add logic to the parent to decide how bad these errors really are. if we
can't initialize a single worker process, just give up. otherwise
Hello all,
SourceLabs is developing a set of tests (and appropriate workload data) to
perform stress testing of an Apache server using requests for static HTML
pages only. We are interested in getting feedback on our plans from the
Apache server community, which has a lot of experience in
How does accept filtering not 'fix' this? If the http accept filter
enabled on FreeBSD, Apache will never even see those bogus requests.
How about linux ? how about Windows ? how about (put your favorite OS
here) ?
Well.. First time i heard about httpready (which looks really nice).
Ivan Barrera A. wrote:
How about linux ? how about Windows ? how about (put your favorite OS
here) ?
Linux has SO_ACCEPTFILTER which doesn't trigger the accept until there
is data, so accept filtering works on Linux too. Windows? No idea.
But I bet an Apache DoS would be the least of your
How about linux ? how about Windows ? how about (put your favorite OS
here) ?
Linux has SO_ACCEPTFILTER which doesn't trigger the accept until there
is data, so accept filtering works on Linux too. Windows? No idea. But
I bet an Apache DoS would be the least of your worries there.
Sergey Ten wrote:
Hello all,
SourceLabs is developing a set of tests (and appropriate workload data) to
perform stress testing of an Apache server using requests for static HTML
pages only. We are interested in getting feedback on our plans from the
Apache server community, which has a lot
Hi Ben,
Thanks for your reply. Comments follow:
Ben Laurie wrote:
The CA is created with the authority key identifier set as a critical
extension.
OpenSSL (including 0.9.7g) chokes (voluntarily) on critical extensions
and as a default issue an error such as Certificate Verification:
Error
Rasmus Lerdorf wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
How does that work with large requests? Doesn't the whole principle
leave you the choice of just moving the DOS attack or breaking
pipelining?
At 11:33 AM 5/3/2005, Rasmus Lerdorf wrote:
Turn on accept filtering and this problem goes away. Or at least
it moves to be a kernel-level issue instead of an Apache one.
Of course this solution is also much more performant and less of
a resource hog.
The problem with your issue is that to
Nick Kew wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
How does that work with large requests? Doesn't the whole principle
leave you the choice of just moving the DOS attack or breaking
pipelining?
You mean
You mean the httpready filter? The accept will trigger once the buffer
is full, so yes, large requests will defeat it eventually, but you still
get the benefit of not tying up an Apache process until the buffer has
been filled. The question was regarding just opening up lots of
connections
Ivan Barrera A. wrote:
You mean the httpready filter? The accept will trigger once the buffer
is full, so yes, large requests will defeat it eventually, but you still
get the benefit of not tying up an Apache process until the buffer has
been filled. The question was regarding just opening up
I did fix an issue last year where even with accept filtering enabled
you could DoS any Apache server by simply opening MaxClients connections
and trickling a carriage return to each connection very slowly. So for
people seeing DoS issues like this, I would suggest upgrading to the
latest
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I don't actually
think this is implemented in the
Rasmus Lerdorf wrote:
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I don't actually
Rasmus Lerdorf wrote:
Nick Kew wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
How does that work with large requests? Doesn't the whole principle
leave you the choice of just moving the DOS attack or
Nick Kew wrote:
I have some recollection of that problem, but not the solution. It's
actually somewhat topical for my client right now. You and Paul have
told us about FreeBSD and Linux; is there also a Solaris equivalent?
(probably not required as they're gradually upgrading it to Linux,
but
Paul Querna wrote:
Rasmus Lerdorf wrote:
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I don't
Hello Paul.
Thank you very much for your time and suggestions.
My comments are inline.
Thanks,
Sergey
-Original Message-
From: Paul Querna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 1:52 PM
To: dev@httpd.apache.org
Cc: [EMAIL PROTECTED]; 'Sergey Ten'
Subject: Re:
Rasmus Lerdorf wrote:
Ya, I got messed up in my other email too.
SO_ACCEPTFILTER is in 2.0.xx.
TCP_DEFER_ACCEPT is in 2.1.xx.
-Paul
By the way Paul, I have been meaning ask, are you falling back from
httpready to dataready on SSL requests in 2.x? I don't see it in
server/listen.c,
Paul Querna wrote:
In real life, I don't believe this is detrimental, since if the
accf_http filter sees data it doesn't understand, it acts just like
accf_data -- and mod_ssl reads the data just like normal.
Hrm.. I am not sure I am convinced of that based on what I have seen on
some
* [EMAIL PROTECTED] wrote:
Author: slive
Date: Tue May 3 17:23:48 2005
New Revision: 168028
URL: http://svn.apache.org/viewcvs?rev=168028view=rev
Log:
Missing ErrorDocument line for Not Acceptable.
Ah no, please revert this. 406 documents are filled by the apache and
setting up a home
32 matches
Mail list logo
