On Sun, Oct 24, 2004 at 11:37:11AM +0100, Joe Orton wrote:
On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
theory 2004/10/22 15:09:54
Modified:perl-framework/Apache-Test Changes
perl-framework/Apache-Test/lib/Apache TestRequest.pm
Log:
On Oct 25, 2004, at 4:33 PM, Geoffrey Young wrote:
let's give david a chance to investigate - either to fix or, if a
quick fix
isn't obvious, revert the behavior.
if david doesn't respond by, say, wednesday, we (you or I) should feel
free
to just revert the change. maybe david is on vacation
--On Sunday, October 24, 2004 8:30 PM -0600 Paul Querna [EMAIL PROTECTED]
wrote:
I took this patch as the starting point for my 'Event MPM'.
...
I would love feedback on all aspects of the patch. Please feel free to rip
it apart :)
I just had a conversation on #apr with Paul. But, I'll rehash
There is currently one showstopper holding up release of 1.3.33.
It has 2 votes for and none against, and it's for backing out
a patch recently applied in mod_rewrite... Please look it
over, otherwise I'll assume a lazy consensus (I know, I know)
and apply it.
Bill,
Did these changes make it into 1.3.32 -- I noticed a lot of changes in
the log for mod_rewrite, but not these ones.
Philip
William A. Rowe, Jr. wrote:
At 12:17 PM 6/21/2004, Philip Gladstone wrote:
Hi,
I discovered that (on Windows) mod_rewrite.c invokes CreateProcess when creating
Roy T. Fielding wrote:
What would make more sense is Error while reading HTTP request line.
(remote browser didn't send a request?). This indicates exactly what
httpd was trying to do when the error occurred, and gives a hint of
why the error might have occurred.
We used to have such a
In the case you just mentioned... it is going to take
a special 'filter' to 'sense' that a possible DOS
attack is in progress. Just fair amounts of 'dataless'
connection requests from one or a small number of orgins
doesn't qualify. There are plenty of official
algorithms around now to
On Tue, 26 Oct 2004 14:51:59 +0100, Ivan Ristic [EMAIL PROTECTED] wrote:
Sure, you may need to have some logic to determine what makes
an attack and what not, but you must have the log entry to
begin with so you feed it to the algorithm.
Something I'm still curious about: Was the
Paul Querna wrote:
The updated patch for today adds multiple processes.
cool!
However, the big thing it doesn't use is accept serialization.
hmmm, that would be challenging with a merged listener/event thread. If the
event thread is blocked waiting for its turn to accept(), it can't react to a
I dont claim to be a java expert but I use apache extensively and figure i
might as well toss in my $.02
Frankly, there are two reasons I hate java.
1) Its a resource hog. Running on a JRE or Virtual Machine setup provides an
extra layer of resource requirements that a similar C, C++,
Greg Ames wrote:
However, the big thing it doesn't use is accept serialization.
hmmm, that would be challenging with a merged listener/event thread. If
the event thread is blocked waiting for its turn to accept(), it can't
react to a poll popping due to an older connection becoming readable.
Justin Erenkrantz wrote:
Um, flood already lets you do this and lots more.
Does flood allow multiple connections per thread or per process? Ideally the
load simulator would scale as well as the server, although that's not strictly
necessary. Eventually I want to run at least as many
Jeff Trawick wrote:
On Tue, 26 Oct 2004 14:51:59 +0100, Ivan Ristic [EMAIL PROTECTED] wrote:
Sure, you may need to have some logic to determine what makes
an attack and what not, but you must have the log entry to
begin with so you feed it to the algorithm.
Something I'm still curious
--On Tuesday, October 26, 2004 11:24 AM -0400 Greg Ames [EMAIL PROTECTED]
wrote:
Does flood allow multiple connections per thread or per process? Ideally
the load simulator would scale as well as the server, although that's not
strictly necessary. Eventually I want to run at least as many
In the case you just mentioned... it is going to take
a special 'filter' to 'sense' that a possible DOS
attack is in progress. Just fair amounts of 'dataless'
connection requests from one or a small number of orgins
doesn't qualify. There are plenty of official
algorithms around now to
Justin Erenkrantz wrote:
this MPM breaks any pipelined connections because there can be a deadlock.
core_input_filter or any connection-level filter (say SSL) could be
holding onto a complete request that hasn't been processed yet. The
worker thread will only process one request and then put it
[EMAIL PROTECTED] wrote:
You MUST have SOMETHING that knows the difference
or you don't have DOS protection.
Also... if you wait all the way until you have a 'log' entry for
a DOS in progress then you haven't achieved the goal
of sensing them 'at the front door'.
I don't set myself that
--On Tuesday, October 26, 2004 12:03 PM -0400 Greg Ames [EMAIL PROTECTED]
wrote:
Yes, this needs to be fixed. I don't see it as difficult problem. We
already test for whether the output filters need to be flushed (i.e., is
there any more data in the input filter chain) before the request ends.
You MUST have SOMETHING that knows the difference
or you don't have DOS protection.
Also... if you wait all the way until you have a 'log' entry for
a DOS in progress then you haven't achieved the goal
of sensing them 'at the front door'.
I don't set myself that goal. I agree that it's
At 07:59 AM 10/26/2004, Philip wrote:
Bill,
Did these changes make it into 1.3.32 -- I noticed a lot of changes in the log for
mod_rewrite, but not these ones.
c.f. http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/modules/standard/mod_rewrite.c
rev 1.194. Thanks again for your patch,
Justin Erenkrantz wrote:
--On Tuesday, October 26, 2004 12:03 PM -0400 Greg Ames
[EMAIL PROTECTED] wrote:
Yes, this needs to be fixed. I don't see it as difficult problem. We
already test for whether the output filters need to be flushed (i.e., is
there any more data in the input filter chain)
--On Tuesday, October 26, 2004 1:53 PM -0400 Greg Ames
[EMAIL PROTECTED] wrote:
right, I understand. check_pipeline_flush already tests whether the
input filters hold any data if I'm not mistaken.
It doesn't quite work like that. check_pipeline_flush (via the EATCRLF
get_brigade call) only
At 01:59 AM 10/26/2004, Justin Erenkrantz wrote:
core_input_filter or any connection-level filter (say SSL) could be holding onto a
complete request that hasn't been processed yet. The worker thread will only process
one request and then put it back on the stack. But, there's certainly no
Justin Erenkrantz wrote:
The problem is that there is no reliable way to determine if there is
more data in the input filters without actually invoking a read.
that sucks IMO, but it does sounds like how the code works today. We do socket
read() syscalls during the MODE_EATCRLF calls that are
--On Tuesday, October 26, 2004 2:20 PM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Justin, that's the purpose of a Poll bucket. If we introduce the
concept, here's the scenario; whenever a 'speculative' or 'non blocking'
read or write is attempted and fails, at whatever depth (the
--On Tuesday, October 26, 2004 4:25 PM -0400 Greg Ames
[EMAIL PROTECTED] wrote:
that sucks IMO, but it does sounds like how the code works today. We do
socket read() syscalls during the MODE_EATCRLF calls that are almost
always unproductive. They could be optimized away. I don't believe 1.3
Justin Erenkrantz wrote:
--On Tuesday, October 26, 2004 4:25 PM -0400 Greg Ames
that sucks IMO, but it does sounds like how the code works today. We do
socket read() syscalls during the MODE_EATCRLF calls that are almost
always unproductive. They could be optimized away. I don't believe 1.3
--On Tuesday, October 26, 2004 4:56 PM -0400 Greg Ames
[EMAIL PROTECTED] wrote:
So I'm thinking that we should see MODE_EATCRLF behave differently when
core_input_filter has data stashed.
I would prefer a more general solution. As I hinted at before, couldn't
AP_MODE_SPECULATIVE with
Justin Erenkrantz wrote:
Connection-level filters like mod_ssl would have to be rewritten to be
async.
or to simply report whether they held on to any data.
This is how EAGAIN return values would work. But, again, I don't think
we could add it easily without changing a lot of filter semantics.
Justin Erenkrantz wrote:
--On Tuesday, October 26, 2004 4:56 PM -0400 Greg Ames
[EMAIL PROTECTED] wrote:
So I'm thinking that we should see MODE_EATCRLF behave differently when
core_input_filter has data stashed.
I would prefer a more general solution. As I hinted at before, couldn't
--On Tuesday, October 26, 2004 6:55 PM -0400 Greg Ames
[EMAIL PROTECTED] wrote:
It might work fine, but we already have a MODE_EATCRLF call which ought
to do the job (down to the core_input_filter anyway) as long as we
remember what it returned. Are you suggesting that we replace that?
Would
Ryan Morgan wrote:
The mod_authnz_ldap documentation states that authorization schemes can be
setup using LDAP filters. From looking at the source, that doesn't appear
to be the case. (Authentication uses filters, but the authorization
phase does not)
I think that type of feature could be useful
On Oct 26, 2004, at 6:10 PM, Graham Leggett wrote:
Ryan Morgan wrote:
The mod_authnz_ldap documentation states that authorization schemes
can be
setup using LDAP filters. From looking at the source, that doesn't
appear
to be the case. (Authentication uses filters, but the authorization
phase
33 matches
Mail list logo
