I'm running gentoo and trying to see my helloworld module which I got
from the apache modules book. So I try to hit
http://10.0.2.20/helloworld, but nothing happens exept that I get a
'file does not exist' in the apache errors.log.
When I run apache2 -M, I don't see my module listed anywhere's.
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Paul Querna wrote:
On Sun, Mar 29, 2009 at 10:44 PM, Paul Querna p...@querna.org wrote:
Inside a MPM that does it natively, just use the registered list of
providers, and implement the same behavoirs as the module.
The problem with mpm is that (IIRC the proposal) it uses
the current free
On Mon, Mar 30, 2009 at 10:48 AM, Mladen Turk mt...@apache.org wrote:
Paul Querna wrote:
On Sun, Mar 29, 2009 at 10:44 PM, Paul Querna p...@querna.org wrote:
Inside a MPM that does it natively, just use the registered list of
providers, and implement the same behavoirs as the module.
The
Ruediger Pluem wrote:
Name based virtual hosting with SSL does *only* work with SNI *enabled*
clients. Not SNI enabled clients receive a 403 when contacting any of
the name based virtual hosts (which enables you to set a nice error
page to explain to the user what happened and which browser to
Paul Querna wrote:
On Mon, Mar 30, 2009 at 10:48 AM, Mladen Turk mt...@apache.org wrote:
Paul Querna wrote:
On Sun, Mar 29, 2009 at 10:44 PM, Paul Querna p...@querna.org wrote:
Inside a MPM that does it natively, just use the registered list of
providers, and implement the same behavoirs as
Dear all,
I find there is an old ddos support apache module called 'mod_evasive'. I
test it on the httpd-2.2.10, it works well. But when I test it on my
Preserve Proxy Apache, it seems that the mod_evasive doesn't work. Because
my hacking log infos dont appear.
Is there any one update this
On Mar 27, 2009, at 9:21 PM, Branko Čibej wrote:
Eric Covener wrote:
On Fri, Mar 27, 2009 at 4:00 PM, Branko Čibej br...@xbc.nu wrote:
Eric Covener wrote:
See the unrelated revisions showing up here:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/support/ab.c?view=log
is this
On Mar 30, 2009, at 5:22 AM, Paul Querna wrote:
On Mon, Mar 30, 2009 at 10:48 AM, Mladen Turk mt...@apache.org
wrote:
Paul Querna wrote:
On Sun, Mar 29, 2009 at 10:44 PM, Paul Querna p...@querna.org
wrote:
Inside a MPM that does it natively, just use the registered list of
providers,
On Mar 29, 2009, at 1:32 PM, Paul Querna wrote:
On Sun, Mar 29, 2009 at 7:28 PM, ntwrkd ntw...@gmail.com wrote:
Can you explain why this would not be accomplishable through
mod_proxy_balancer and would merit it's own module?
1) it is not currently possibly to add proxy workers without a
On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
URL Authentication is done by computing an randomly seeded md5
signature of:
seed + $+ MD5(seed + shared_secret + uri)
This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
Thinking outloud here... The idea I think is to
FWIW, this means that apr-1.4 is no longer viable for httpd-trunk.
As of a few days ago, I could build with 1.4.x no longer.
Are we *sure* we want to do that?
Just asking :)
On Mar 29, 2009, at 12:05 PM, mt...@apache.org wrote:
Author: mturk
Date: Sun Mar 29 16:05:53 2009
New Revision:
Jim Jagielski wrote:
fine, disagree with that, but what are your thoughts on switching to
the provider API?
+1 to provider... it's one of the best parts of httpd
But it uses the provider already :)
Regards
--
^(TM)
On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski j...@jagunet.com wrote:
On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
URL Authentication is done by computing an randomly seeded md5 signature
of:
seed + $+ MD5(seed + shared_secret + uri)
This is base64 encoded, and placed in a
IMHO we shouldn't require APR 2.0 for trunk (although trunk should be capable
to run with 2.0).
Apart from the other stuff you mentioned before it makes it much harder to cut
2.4.
So I am -1 on this change until APR 2.0 is at least in beta state.
So Mladen please revert.
Regards
Rüdiger
Jim Jagielski wrote:
FWIW, this means that apr-1.4 is no longer viable for httpd-trunk.
As of a few days ago, I could build with 1.4.x no longer.
Are we *sure* we want to do that?
I was under the impression that apr-2 is now mandatory,
regardless of the apr-2 permission setter api.
Plüm, Rüdiger, VF-Group wrote:
IMHO we shouldn't require APR 2.0 for trunk (although trunk should be capable
to run with 2.0).
Apart from the other stuff you mentioned before it makes it much harder to cut
2.4.
So I am -1 on this change until APR 2.0 is at least in beta state.
So Mladen
-Ursprüngliche Nachricht-
Von: Paul Querna
Gesendet: Montag, 30. März 2009 17:04
An: dev@httpd.apache.org
Betreff: Re: [PROPOSAL] mod_cloudbeat
On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski
j...@jagunet.com wrote:
On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
URL
-Ursprüngliche Nachricht-
Von: Mladen Turk
Gesendet: Montag, 30. März 2009 17:08
An: dev@httpd.apache.org
Betreff: Re: svn commit: r759711 - /httpd/httpd/trunk/os/unix/unixd.c
Jim Jagielski wrote:
FWIW, this means that apr-1.4 is no longer viable for httpd-trunk.
As of a
-Ursprüngliche Nachricht-
Von: Mladen Turk
Gesendet: Montag, 30. März 2009 17:11
An: dev@httpd.apache.org
Betreff: Re: svn commit: r759711 - /httpd/httpd/trunk/os/unix/unixd.c
Plüm, Rüdiger, VF-Group wrote:
IMHO we shouldn't require APR 2.0 for trunk (although trunk
should
On Mon, Mar 30, 2009 at 5:10 PM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Ursprüngliche Nachricht-
Von: Paul Querna
Gesendet: Montag, 30. März 2009 17:04
An: dev@httpd.apache.org
Betreff: Re: [PROPOSAL] mod_cloudbeat
On Mon, Mar 30, 2009 at 4:45 PM, Jim Jagielski
On Mar 30, 2009, at 10:45 AM, Jim Jagielski wrote:
On Mar 29, 2009, at 11:43 AM, Paul Querna wrote:
URL Authentication is done by computing an randomly seeded md5
signature of:
seed + $+ MD5(seed + shared_secret + uri)
This is base64 encoded, and placed in a 'X-Cloudbeat-Auth' header.
-Ursprüngliche Nachricht-
Von: Paul Querna
Gesendet: Montag, 30. März 2009 17:18
An: dev@httpd.apache.org
Betreff: Re: [PROPOSAL] mod_cloudbeat
On Mon, Mar 30, 2009 at 5:10 PM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Ursprüngliche Nachricht-
On Mon, Mar 30, 2009 at 5:28 PM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Ursprüngliche Nachricht-
Von: Paul Querna
Gesendet: Montag, 30. März 2009 17:18
An: dev@httpd.apache.org
Betreff: Re: [PROPOSAL] mod_cloudbeat
On Mon, Mar 30, 2009 at 5:10 PM, Plüm,
On Mar 30, 2009, at 11:28 AM, Plüm, Rüdiger, VF-Group wrote:
But it doesn't prevent A' that sniffed the traffic from A to B to
replay.
OTOH why fiddle with this auth stuff anyway. We could make it save by
using TLS and client certs.
Holy freholey! And I was worried about the overhead of
Ruediger Pluem wrote:
Going through the archive I noticed several attachments with the same
basename and and a version string attached. Are these patches
cumulative so that I only need to review the latest one?
sni_sslverifyclient-v5.diff includes all improvements to
On 03/30/2009 10:08 AM, mt...@apache.org wrote:
Author: mturk
Date: Mon Mar 30 08:07:59 2009
New Revision: 759862
URL: http://svn.apache.org/viewvc?rev=759862view=rev
Log:
Use named watchdog for heartmonitor.
The watchdog has zero interval, leaving to the callback to determine the
On Mar 30, 2009, at 2:39 PM, Ruediger Pluem wrote:
IMHO we should do apr_pool_create *once * before the loop and
apr_pool_destroy *after* the lookp. In the loop we should only use
apr_pool_clear. apr_pool_create and apr_pool_destroy require locking
which seems to be an unneeded overhead here.
Does anybody know if the below comment from connection.c is still true?
* In an ideal world, this function would be accomplished by simply
* setting the socket option SO_LINGER and handling it within the
* server's TCP stack while the process continues on to the next request.
*
On Mon, Mar 30, 2009 at 3:00 PM, Ruediger Pluem rpl...@apache.org wrote:
Does anybody know if the below comment from connection.c is still true?
* In an ideal world, this function would be accomplished by simply
* setting the socket option SO_LINGER and handling it within the
* server's
Jim Jagielski wrote:
due to the refactorings as well. Does it make sense to branch
off 2.4 before we go further?
Nah... 2.4? 3.0? That seems like a value judgement once things
stabilize.
We can leave out 'not yet ready' modules. We shouldn't leave out
the changes required to core; we
Plüm, Rüdiger, VF-Group wrote:
IMHO we shouldn't require APR 2.0 for trunk (although trunk should be capable
to run with 2.0).
+1
-1 (veto)
Filling obscure areas of the server with stupid hacks that modify
the request structure because of something the content generator
*might* do is harmful to overall stability. 204 and 304 are already
handled elsewhere (or, if not, they should be handled elsewhere).
Roy
On Mar 30,
mod_watchdog is the latest offender in a series of modules that expose
additional functions to the API. (mod_proxy and mod_cache do too!)
What happened to all functions that are not inside server/* must be
either dynamic optional functions or hooks?
Doesn't anyone remember the load order pain of
Paul Querna wrote:
mod_watchdog is the latest offender in a series of modules that expose
additional functions to the API. (mod_proxy and mod_cache do too!)
What happened to all functions that are not inside server/* must be
either dynamic optional functions or hooks?
Doesn't anyone remember
On Mar 30, 2009, at 7:37 PM, Paul Querna wrote:
mod_watchdog is the latest offender in a series of modules that expose
additional functions to the API. (mod_proxy and mod_cache do too!)
What happened to all functions that are not inside server/* must be
either dynamic optional functions or
On Mon, Mar 30, 2009 at 11:36 PM, William A. Rowe, Jr.
wr...@rowe-clan.net wrote:
Plüm, Rüdiger, VF-Group wrote:
IMHO we shouldn't require APR 2.0 for trunk (although trunk should be
capable to run with 2.0).
+1
+1. -- justin
37 matches
Mail list logo
