You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2007/08/30 14:31:21 UTC
Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Since a few regressions and other issues popped up the
last go around, I cancelled release of 1.3.38, 2.0.60 and
2.2.5... I think we are close, *very* close to being at
the point to try this all again.
1.3.39 looks stable enough that a T&R has no open issues
at all. So it's a no-brainer.
2.0.61 also looks the same, although we do have a bundled
later version of apr/apu.
2.2.6 has a few items still in STATUS which lack a single
vote to be backported. Now I'm not asking that people
just vote, but I am asking that people take a good look
at the proposals, test them out and vote as they see fit.
I don't want to delay 2.2.6 any more than it needs to be,
yet on the other hand it would be a shame not to release
2.2.6 with as many improvements and fixes as possible.
My intent is to T&R all 3 tomorrow (Friday, the 31st) with
a potential announcement Wednesday, Sept 5th. This is
because Monday is a holiday in the states, so that means
mostly a 3 day weekend for most people...
RE: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
>>-----Message d'origine-----
>>De : Plüm, Rüdiger, VF-Group [mailto:ruediger.pluem@vodafone.com]
>>Envoyé : lundi 3 septembre 2007 10:35
>>À : dev@httpd.apache.org
>>Objet : Re: Apache 2.2.x: Implicit creation of new proxy_workers
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Axel-Stéphane SMORGRAV
>>
>> Gesendet: Montag, 3. September 2007 10:05
>> An: dev@httpd.apache.org
>> Betreff: RE: Apache 2.2.x: Implicit creation of new proxy_workers
>>
>>
>> Persistent backend connection when proxying using RewriteRule is
>> exactly what I am trying to do.
>>
>> AFAIU there is no way to achieve persistent connections with the
>> default worker because (correct me if I am wrong) a worker is
>> associated with a single proxy_conn_pool and the proxy_conn_pool is
>> associated with a single address, and in the case of the default
>> worker the address may be different each time the worker is used.
>>
>> This means that the only way to make these backend connections
>> persistent is to create at least one worker per backend. Right?
>
>Correct.
>
Some questions:
1. Since the backend address is not known to the configuration, isn't the only way to create a worker for "dynamic" backends to create them as they occur ?
2. Does what I suggest seem like a viable/sensible solution ? Should it be supplemented with a setting to activate/de-activate the on-the-fly creation of new workers ?
3. Any idea why I end up with a mutex problem and the aforementioned error, or how to go about debugging it ?
BR
-ascs
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 4, 2007, at 8:27 AM, Axel-Stéphane SMORGRAV wrote:
>> -----Message d'origine-----
>> De : Axel-Stéphane SMORGRAV
>> Envoyé : mardi 4 septembre 2007 14:19
>> À : dev@httpd.apache.org
>> Objet : [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>>
>>
>> I will create a Bugzilla report for this issue.
>>
>
> On second thought I will not create a report in Bugzilla - I
> thought suggestions for improvements could be filed that way...
>
> How can we move forward on this issue ?
>
I would still file it under BUGZ.
RE: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
>-----Message d'origine-----
>De : Axel-Stéphane SMORGRAV
>Envoyé : mardi 4 septembre 2007 14:19
>À : dev@httpd.apache.org
>Objet : [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>
>
>I will create a Bugzilla report for this issue.
>
On second thought I will not create a report in Bugzilla - I thought suggestions for improvements could be filed that way...
How can we move forward on this issue ?
-ascs
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 17, 2007, at 6:58 AM, Nick Kew wrote:
>
> Instead of limiting the number and thus creating them randomly
> (according to what traffic happens to hit the server first),
>
>
That is part of, I think, both Rüdiger's and my concern.
The benefits are this are really really fuzzy when applied
to the real world. If you know enough about how the proxies
will be used, then trying to figure out how to do
it with ProxyPass (esp. now with the Match version) is
likely better.
If not, then creating a limit means that the ones created
first get the benefits and the ones "after" the limit don't.
To me, this implies some sort of staleness factor should
be implemented, such that if "older" ones haven't been
used they should be removed to make space for
newer ones...
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 17 Sep 2007 13:29:44 +0200
Axel-Stéphane SMORGRAV <Ax...@europe.adp.com> wrote:
> I do not
> really see why this should be done in another module, though.
How about:
1. It's a well-defined task (isn't it)?, and therefore a natural
candidate for a module in a modular server.
2. Because it's a lot of extra complexity, it should remain optional.
3. Separating it out will help maintainability. Or rather, failing
to do so will tend to be a maintenance nightmare.
4. If we get around to refactoring mod_proxy to provide separate
forward and reverse proxy modules, a worker management module
will be a useful optional extra for both to have.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
RE: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
-----Message d'origine-----
>De : Nick Kew [mailto:nick@webthing.com]
>Envoyé : lundi 17 septembre 2007 12:59
>À : dev@httpd.apache.org
>Objet : Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>
>On Mon, 17 Sep 2007 11:33:16 +0200
>Axel-Stéphane SMORGRAV <Ax...@europe.adp.com> wrote:
>
>Instead of limiting the number and thus creating them randomly (according
>to what traffic happens to hit the server first), wouldn't it be better
>to introduce a configuration directive to create your choice of those extra
>workers at startup?
That configuration directive already exists: it's called ProxyPass.
RewriteRule / http://server/ [P]
ProxyPass / !
ProxyPass / http://server/
Been there, done that. Works well provided you have an exhaustive list of backends at the time the server is started.
The list of our backends resides in a RewriteMap so that approach is not practical.
>If your config is such that specifying the workers isn't going to work, then
>managing them dynamically in a useful manner is going to be a complex job
>that should probably have its own separate module, based on a reslist and a
>usage-counting strategy to drop little-used workers.
>Or something like that.
A separate pool of dynamically created workers, of limited size known at configuration time, with a LRU replacement strategy whenever we run out of workers would indeed be a very elegant solution. I do not really see why this should be done in another module, though.
BR
-ascs
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 17 Sep 2007 11:33:16 +0200
Axel-Stéphane SMORGRAV <Ax...@europe.adp.com> wrote:
> >To be honest I am still not convinced that the dynamic creation of
> >workers is a good idea at all.
Indeedie.
> I believe I have addressed your concerns in a new patch posted for
> PR#43308 in which I introduce a new configuration directive that
> limits the number of dynamically created workers. During
> configuration I also increment proxy_lb_workers by the value of
> ProxyMaxAddtlWorkers in order (at least I hope) for additional
> scoreboard entries to be allocated...
Instead of limiting the number and thus creating them randomly
(according to what traffic happens to hit the server first),
wouldn't it be better to introduce a configuration directive
to create your choice of those extra workers at startup?
If your config is such that specifying the workers isn't
going to work, then managing them dynamically in a useful
manner is going to be a complex job that should probably
have its own separate module, based on a reslist and a
usage-counting strategy to drop little-used workers.
Or something like that.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
RE: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
-----Message d'origine-----
>De : Plüm, Rüdiger, VF-Group [mailto:ruediger.pluem@vodafone.com]
>Envoyé : lundi 10 septembre 2007 12:02
>À : dev@httpd.apache.org
>Objet : Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>
>> -----Ursprüngliche Nachricht-----
>> Von: Nick Kew
>> Gesendet: Montag, 10. September 2007 11:29
>> An: dev@httpd.apache.org
>> Betreff: Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>>
>> Does this open the way to a DoS? If a rewriterule[P] enables backends
>> to be derived from the request URI, then you're creating unlimited
>> numbers of workers, which may never be used. Where are the limits on
>> that?
>
>Also the scoreboard is a limiting factor for this. The number of available
>scoreboard entries is determined during the configuration phase of the startup
>(it cannot even be changed during graceful starts, this is why we add some
>additional entries to the number of workers we have counted in the configuration).
>
>To be honest I am still not convinced that the dynamic creation of workers is a good idea at all.
>
I believe I have addressed your concerns in a new patch posted for PR#43308 in which I introduce a new configuration directive that limits the number of dynamically created workers. During configuration I also increment proxy_lb_workers by the value of ProxyMaxAddtlWorkers in order (at least I hope) for additional scoreboard entries to be allocated...
BR
-ascs
RE: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
-----Message d'origine-----
>De : Jim Jagielski [mailto:jim@jaguNET.com]
>Envoyé : lundi 10 septembre 2007 14:00
>À : dev@httpd.apache.org
>Objet : Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>
>
>On Sep 10, 2007, at 6:01 AM, Plüm, Rüdiger, VF-Group wrote:
>
>>
>> Also the scoreboard is a limiting factor for this. The number of
>> available scoreboard entries is determined during the configuration
>> phase of the startup (it cannot even be changed during graceful
>> starts, this is why we add some additional entries to the number of
>> workers we have counted in the configuration).
>>
>> To be honest I am still not convinced that the dynamic creation of
>> workers is a good idea at all.
>>
>
>I agree...
Thanks for your feedback. The issues mentioned in this thread are exactly what I was a little worried about. However:
1. I do not really see how that could be used in a DOS attack as long as the client cannot specify the address of the backend connection ( e.g. a rewrite rule that retrieves the backend address in some query parameter, but that would represent a security issue under any circumstances ).
2. For all practical purposes the number of backends is rather limited ( a dozen ), at least in the configurations that we use.
3. Comparative load tests we have made with and without persistent client connections show that there is a significant performance gain when using persistent connections, both in terms of response times and in terms of reduced load on the backend servers. There is no reason to believe that a similar gain in performance cannot be achieved also with persistent backend connections.
The problems you mention can be limited or eliminated by putting a configurable limit on the number of proxy workers created dynamically, the default being 0 (none). One could even imagine adding an equivalent number of slots to the scoreboard.
I therefore suggest supplementing the previously described mechanism with an additional configuration directive, e.g. ProxyAddtlWorkersMax, default 0, with which one can specify the maximum number of implicitly created workers. An equivalent number of additional scoreboard entries will be allocated during the configuration phase.
I hope this is enough to address your concerns.
BR
-ascs
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 10, 2007, at 6:01 AM, Plüm, Rüdiger, VF-Group wrote:
>
> Also the scoreboard is a limiting factor for this. The number of
> available
> scoreboard entries is determined during the configuration phase of the
> startup (it cannot even be changed during graceful starts, this is
> why we
> add some additional entries to the number of workers we have
> counted in the
> configuration).
>
> To be honest I am still not convinced that the dynamic creation of
> workers
> is a good idea at all.
>
I agree...
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Nick Kew
> Gesendet: Montag, 10. September 2007 11:29
> An: dev@httpd.apache.org
> Betreff: Re: [PATCH] Apache 2.2.x: Implicit creation of new
> proxy_workers
>
>
> On Tue, 4 Sep 2007 14:19:23 +0200
> Axel-Stéphane SMORGRAV <Ax...@europe.adp.com> wrote:
>
> > I will create a Bugzilla report for this issue.
>
> That'll be PR#43308, in which you wrote:
>
> > In Apache 2.2.x a worker, and the associated backend
> connection pool,
> > is created for each ProxyPass directive. In that case the backend
> > connections will by default be persistent (reusable).
>
> > (chop - RewriteRule [P])
>
> > I therefore suggest to modify ap_proxy_pre_request() in order to
> > create new workers as needed in the event of requests that do not
> > match an existing worker.
>
> Does this open the way to a DoS? If a rewriterule[P] enables backends
> to be derived from the request URI, then you're creating unlimited
> numbers of workers, which may never be used. Where are the limits
> on that?
Also the scoreboard is a limiting factor for this. The number of available
scoreboard entries is determined during the configuration phase of the
startup (it cannot even be changed during graceful starts, this is why we
add some additional entries to the number of workers we have counted in the
configuration).
To be honest I am still not convinced that the dynamic creation of workers
is a good idea at all.
Regards
Rüdiger
Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 4 Sep 2007 14:19:23 +0200
Axel-Stéphane SMORGRAV <Ax...@europe.adp.com> wrote:
> I will create a Bugzilla report for this issue.
That'll be PR#43308, in which you wrote:
> In Apache 2.2.x a worker, and the associated backend connection pool,
> is created for each ProxyPass directive. In that case the backend
> connections will by default be persistent (reusable).
> (chop - RewriteRule [P])
> I therefore suggest to modify ap_proxy_pre_request() in order to
> create new workers as needed in the event of requests that do not
> match an existing worker.
Does this open the way to a DoS? If a rewriterule[P] enables backends
to be derived from the request URI, then you're creating unlimited
numbers of workers, which may never be used. Where are the limits
on that?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
[PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
>-----Message d'origine-----
>De : Jim Jagielski [mailto:jim@jaguNET.com]
>Envoyé : lundi 3 septembre 2007 14:56
>À : dev@httpd.apache.org
>Objet : Re: Apache 2.2.x: Implicit creation of new proxy_workers
>
>
>That's right. You can't really have a connection pool if the
>endpoint is unknown or changing :)
>
>You could of course, as you said, create a patch which,
>once the generic worker is used, "add" it to the pool,
>but this is not trivial to do as 1st glance.
First of all, thanks for your comments (Jim + Rüdiger).
I finally managed to get a working implementation of what I initially proposed, which was to create new workers on the fly as new backends for which no worker exists appear. This can happen if a RewriteRule proxies a request (with the [P] flag), and the backend URL does not match any of the ProxyPass' second argument (URL).
1. New workers are created for scheme://address/. The URL path is ignored. One might want to add a new configuration directive for specifying the number of path elements to include in the worker name.
2. The request for which the worker is created is served using the default worker. The connection pool for the new worker is then only populated on the first request matching the new worker (the 2nd request), and an existing connection may only be reused from the following request on.
3. There is no way to tune the connection pooling of the workers created on-the-fly.
4. One might want to add a new configuration directive for (de-)activating this mechanism
Regarding the implementation details, being a novice to Apache development, I look forward to your comments. However
i) PROXY_COPY_CONF_PARAMS should probably be moved to mod_proxy.h to avoid duplication
ii) I allocate a copy of the URL on the stack rather than out of the pool since as far as I could see, it is duplicated in ap_proxy_add_worker() anyway
iii) Someone skilled in the art of Apache httpd development could probably come up with a way that the newly created worker could be used immediately instead of having to wait for the next request.
I will create a Bugzilla report for this issue.
BR
-ascs
Re: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 3, 2007, at 4:05 AM, Axel-Stéphane SMORGRAV wrote:
> Persistent backend connection when proxying using RewriteRule is
> exactly what I am trying to do.
>
> AFAIU there is no way to achieve persistent connections with the
> default worker because (correct me if I am wrong) a worker is
> associated with a single proxy_conn_pool and the proxy_conn_pool is
> associated with a single address, and in the case of the default
> worker the address may be different each time the worker is used.
>
> This means that the only way to make these backend connections
> persistent is to create at least one worker per backend. Right?
>
That's right. You can't really have a connection pool if the
endpoint is unknown or changing :)
You could of course, as you said, create a patch which,
once the generic worker is used, "add" it to the pool,
but this is not trivial to do as 1st glance.
Re: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Axel-Stéphane SMORGRAV
>
> Gesendet: Montag, 3. September 2007 10:05
> An: dev@httpd.apache.org
> Betreff: RE: Apache 2.2.x: Implicit creation of new proxy_workers
>
>
> Persistent backend connection when proxying using RewriteRule
> is exactly what I am trying to do.
>
> AFAIU there is no way to achieve persistent connections with
> the default worker because (correct me if I am wrong) a
> worker is associated with a single proxy_conn_pool and the
> proxy_conn_pool is associated with a single address, and in
> the case of the default worker the address may be different
> each time the worker is used.
>
> This means that the only way to make these backend
> connections persistent is to create at least one worker per
> backend. Right?
Correct.
Regards
Rüdiger
RE: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
Persistent backend connection when proxying using RewriteRule is exactly what I am trying to do.
AFAIU there is no way to achieve persistent connections with the default worker because (correct me if I am wrong) a worker is associated with a single proxy_conn_pool and the proxy_conn_pool is associated with a single address, and in the case of the default worker the address may be different each time the worker is used.
This means that the only way to make these backend connections persistent is to create at least one worker per backend. Right?
BR
-ascs
-----Message d'origine-----
De : Plüm, Rüdiger, VF-Group [mailto:ruediger.pluem@vodafone.com]
Envoyé : lundi 3 septembre 2007 09:23
À : dev@httpd.apache.org
Objet : Re: Apache 2.2.x: Implicit creation of new proxy_workers
> -----Ursprüngliche Nachricht-----
> Von: Axel-Stéphane SMORGRAV
>
> Gesendet: Montag, 3. September 2007 08:15
> An: dev@httpd.apache.org
> Betreff: RE: Apache 2.2.x: Implicit creation of new proxy_workers
>
>
> What if the backend address is not known in the configuration because
> computed dynamically using for example RewriteMap ?
I do not get the point in this case. There is always a default reverse proxy worker that is used when no other worker is there. It has the limititation that you cannot adjust its parameters and that it does not support keepalives. But if you create workers dynamically this would not be very different (except for the keepalive issue).
Regards
Rüdiger
Re: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Axel-Stéphane SMORGRAV
>
> Gesendet: Montag, 3. September 2007 08:15
> An: dev@httpd.apache.org
> Betreff: RE: Apache 2.2.x: Implicit creation of new proxy_workers
>
>
> What if the backend address is not known in the configuration
> because computed dynamically using for example RewriteMap ?
I do not get the point in this case. There is always a default reverse
proxy worker that is used when no other worker is there. It has the
limititation that you cannot adjust its parameters and that it does
not support keepalives. But if you create workers dynamically this
would not be very different (except for the keepalive issue).
Regards
Rüdiger
RE: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
What if the backend address is not known in the configuration because computed dynamically using for example RewriteMap ?
In that case I cannot see any other way of doing this than creating the worker on the fly, and unfortunately with my current modifications I sooner or later end up getting the following error:
[Fri Aug 31 15:32:19 2007] [emerg] (os 0x001ebf50)Unrecognized resolver error: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
BR
-ascs
-----Message d'origine-----
De : Plüm, Rüdiger, VF-Group [mailto:ruediger.pluem@vodafone.com]
Envoyé : vendredi 31 août 2007 18:20
À : dev@httpd.apache.org
Objet : Re: Apache 2.2.x: Implicit creation of new proxy_workers
> -----Ursprüngliche Nachricht-----
> Von: Axel-Stéphane SMORGRAV
> [mailto:Axel-Stephane.SMORGRAV@europe.adp.com]
> Gesendet: Freitag, 31. August 2007 16:02
> An: dev@httpd.apache.org
> Betreff: Apache 2.2.x: Implicit creation of new proxy_workers
>
>
> Hi,
>
> In order for URLs proxied using RewriteRule with the P-flag to benefit
> from proxy worker connection pools, I have
I guess there is a better way to do this. Simply use
<Proxy ajp://worker/somewhere>
ProxySet keepalive=On
</Proxy>
But currently this only works on trunk. The backport proposals for 2.2.x are missing one vote.
Come on guys (Mladen, Nick) please have a look :-).
There is even a documentation for ProxySet now (Thanks to Jim).
Regards
Rüdiger
Re: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/31/2007 06:20 PM, Plüm wrote:
>
> But currently this only works on trunk. The backport proposals
> for 2.2.x are missing one vote.
> Come on guys (Mladen, Nick) please have a look :-).
Thanks Nick for reviewing.
Regards
Rüdiger
Re: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 31, 2007, at 12:20 PM, Plüm, Rüdiger, VF-Group wrote:
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Axel-Stéphane SMORGRAV
>> [mailto:Axel-Stephane.SMORGRAV@europe.adp.com]
>> Gesendet: Freitag, 31. August 2007 16:02
>> An: dev@httpd.apache.org
>> Betreff: Apache 2.2.x: Implicit creation of new proxy_workers
>>
>>
>> Hi,
>>
>> In order for URLs proxied using RewriteRule with the P-flag
>> to benefit from proxy worker connection pools, I have
>
> I guess there is a better way to do this. Simply use
>
> <Proxy ajp://worker/somewhere>
> ProxySet keepalive=On
> </Proxy>
>
Agreed that it's better, but not obvious... Seems to
me that all these hints and tricks would be useful
to document... Looks like an additional handout for my
ApacheCon US session ;)
Re: Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Axel-Stéphane SMORGRAV
> [mailto:Axel-Stephane.SMORGRAV@europe.adp.com]
> Gesendet: Freitag, 31. August 2007 16:02
> An: dev@httpd.apache.org
> Betreff: Apache 2.2.x: Implicit creation of new proxy_workers
>
>
> Hi,
>
> In order for URLs proxied using RewriteRule with the P-flag
> to benefit from proxy worker connection pools, I have
I guess there is a better way to do this. Simply use
<Proxy ajp://worker/somewhere>
ProxySet keepalive=On
</Proxy>
But currently this only works on trunk. The backport proposals
for 2.2.x are missing one vote.
Come on guys (Mladen, Nick) please have a look :-).
There is even a documentation for ProxySet now (Thanks to Jim).
Regards
Rüdiger
Apache 2.2.x: Implicit creation of new proxy_workers
Posted by Axel-Stéphane SMORGRAV <Ax...@europe.adp.com>.
Hi,
In order for URLs proxied using RewriteRule with the P-flag to benefit from proxy worker connection pools, I have experimented a modification of mod_proxy that implicitly creates a new worker whenever no worker is found for a request. The patch below is against proxy_util.c of Apache 2.2.4.
The code somehow seems to work as intended: on the first occurence of a URL rewritten to proxy: a new worker is created, a connection is opened and added to the worker resource pool. On the second occurence of the URL previously proxied, it gets the previously created worker and reuses an existing connection to the backend.
However I enventually get the following error:
[Fri Aug 31 15:32:19 2007] [emerg] (os 0x001ebf50)Unrecognized resolver error: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
It seems like the server does not appreciate the initialisation of a new worker during request processing...
Some questions:
1. Has initialising new workers this way been discussed among the developers and rejected for some reason ?
2. Is what I propose feasible ?
3. Any idea about how to avoid the above mentioned error or otherwise other suggestions regarding the implementation of this feature?
Thanks
-ascs
*** proxy_util.c.orig Tue Dec 19 22:56:16 2006
--- proxy_util.c Fri Aug 31 14:26:03 2007
***************
*** 20,25 ****
--- 20,35 ----
#include "scoreboard.h"
#include "apr_version.h"
+ #define PROXY_COPY_CONF_PARAMS(w, c) \
+ do { \
+ (w)->timeout = (c)->timeout; \
+ (w)->timeout_set = (c)->timeout_set; \
+ (w)->recv_buffer_size = (c)->recv_buffer_size; \
+ (w)->recv_buffer_size_set = (c)->recv_buffer_size_set; \
+ (w)->io_buffer_size = (c)->io_buffer_size; \
+ (w)->io_buffer_size_set = (c)->io_buffer_size_set; \
+ } while (0)
+
#if APR_HAVE_UNISTD_H
#include <unistd.h> /* for getpid() */
#endif
***************
*** 1394,1407 ****
}
else if (r->proxyreq == PROXYREQ_REVERSE) {
if (conf->reverse) {
- ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
- "proxy: *: found reverse proxy worker for %s",
- *url);
*balancer = NULL;
! *worker = conf->reverse;
access_status = OK;
}
! }
}
else if (access_status == DECLINED && *balancer != NULL) {
/* All the workers are busy */
--- 1404,1434 ----
}
else if (r->proxyreq == PROXYREQ_REVERSE) {
if (conf->reverse) {
*balancer = NULL;
! const char *err = ap_proxy_add_worker(worker, conf->pool, conf, *url);
! if (err) {
! ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
! "proxy: unable to add new reverse proxy worker for %s - %s",
! *url, err);
! ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
! "proxy: *: found reverse proxy worker for %s",
! *url);
! *worker = conf->reverse;
! }
! else
! {
! PROXY_COPY_CONF_PARAMS((proxy_worker *) *worker, (proxy_server_conf *) conf);
!
! ap_proxy_initialize_worker_share(conf, *worker, r->server);
! ap_proxy_initialize_worker(*worker, r->server);
! /* Do not disable worker in case of errors */
! (*worker)->s->status |= PROXY_WORKER_IGNORE_ERRORS;
! /* Disable address cache for generic reverse worker */
! (*worker)->is_address_reusable = 1;
! }
access_status = OK;
}
! }
}
else if (access_status == DECLINED && *balancer != NULL) {
/* All the workers are busy */
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 30, 2007, at 8:31 AM, Jim Jagielski wrote:
>
> My intent is to T&R all 3 tomorrow (Friday, the 31st) with
> a potential announcement Wednesday, Sept 5th. This is
> because Monday is a holiday in the states, so that means
> mostly a 3 day weekend for most people...
>
Due to some last minute patches, and a regression being
fixed in APR, I will be doing the T&R over the weekend
rather than before...
RE: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Cameron Young <ca...@tpg.com.au>.
Thanks Jim.
Allows me to do the correct maths.
I'm in Australia (East Coast).
Cheers,
Cameron
-----Original Message-----
From: Jim Jagielski [mailto:jim@jaguNET.com]
Sent: Friday, 31 August 2007 00:13
To: dev@httpd.apache.org
Subject: Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Well... I'm east coast :)
On Aug 30, 2007, at 9:48 AM, Cameron J. Young ((Personal)) wrote:
> Jim,
> Is that EST or PST ??
> Cheers,
> Cameron
>
> -----Original Message-----
> From: Jim Jagielski [mailto:jim@jaguNET.com]
> Sent: Thursday, 30 August 2007 23:02
> To: dev@httpd.apache.org
> Subject: Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
>
> Yes, the CHANGES file will be updated to reflect any
> and all security issues for that release...
>
> On Aug 30, 2007, at 8:38 AM, Joe Orton wrote:
>
>> On Thu, Aug 30, 2007 at 08:31:21AM -0400, Jim Jagielski wrote:
>>> Since a few regressions and other issues popped up the
>>> last go around, I cancelled release of 1.3.38, 2.0.60 and
>>> 2.2.5... I think we are close, *very* close to being at
>>> the point to try this all again.
>>
>> Can we move the SECURITY stuff back up to the top and remove the
>> 2.2.5
>> heading - it would just be confusing to users since 2.2.5 doen't
>> really
>> exist? i.e. below, which adds the CVE name for the autoindex issue
>> too.
>>
>> Index: CHANGES
>> ===================================================================
>> --- CHANGES (revision 571136)
>> +++ CHANGES (working copy)
>> @@ -1,11 +1,37 @@
>> -*-
>> coding: utf-8 -*-
>> Changes with Apache 2.2.6
>>
>> - *) mod_autoindex: Add in Type and Charset options to IndexOptions
>> + *) SECURITY: CVE-2007-4465 (cve.mitre.org)
>> + mod_autoindex: Add in Type and Charset options to IndexOptions
>> directive. This allows the admin to explicitly set the
>> content-type and charset of the generated page.
>> [Jim Jagielski]
>>
>> + *) SECURITY: CVE-2007-3847 (cve.mitre.org)
>> + mod_proxy: Prevent reading past the end of a buffer when
>> parsing
>> + date-related headers. PR 41144.
>> + [Davi Arnaut, Nick Kew]
>> +
>> + *) SECURITY: CVE-2007-1863 (cve.mitre.org)
>> + mod_cache: Prevent a segmentation fault if attributes are
>> listed in a
>> + Cache-Control header without any value.
>> + [Niklas Edmundsson <nikke acc.umu.se>]
>> +
>> + *) SECURITY: CVE-2007-3304 (cve.mitre.org)
>> + prefork, worker, event MPMs: Ensure that the parent process
>> cannot
>> + be forced to kill processes outside its process group.
>> + [Joe Orton, Jim Jagielski]
>> +
>> + *) SECURITY: CVE-2006-5752 (cve.mitre.org)
>> + mod_status: Fix a possible XSS attack against a site with a
>> public
>> + server-status page and ExtendedStatus enabled, for browsers
>> which
>> + perform charset "detection". Reported by Stefan Esser. [Joe
>> Orton]
>> +
>> + *) SECURITY: CVE-2007-1862 (cve.mitre.org)
>> + mod_mem_cache: Copy headers into longer lived storage; header
>> names and
>> + values could previously point to cleaned up storage. PR 41551.
>> + [Davi Arnaut <davi haxent.com.br>]
>> +
>> *) log core: ensure we use a special pool for stderr logging, so
>> that
>> the stderr channel remains valid from the time plog is
>> destroyed,
>> until the time the open_logs hook is called again. [William
>> Rowe]
>> @@ -70,33 +96,6 @@
>> improper merging of the cache lock in vhost config
>> PR 43164 [Eric Covener]
>>
>> -Changes with Apache 2.2.5
>> -
>> - *) SECURITY: CVE-2007-3847 (cve.mitre.org)
>> - mod_proxy: Prevent reading past the end of a buffer when
>> parsing
>> - date-related headers. PR 41144.
>> - [Davi Arnaut, Nick Kew]
>> -
>> - *) SECURITY: CVE-2007-1863 (cve.mitre.org)
>> - mod_cache: Prevent a segmentation fault if attributes are
>> listed in a
>> - Cache-Control header without any value.
>> - [Niklas Edmundsson <nikke acc.umu.se>]
>> -
>> - *) SECURITY: CVE-2007-3304 (cve.mitre.org)
>> - prefork, worker, event MPMs: Ensure that the parent process
>> cannot
>> - be forced to kill processes outside its process group.
>> - [Joe Orton, Jim Jagielski]
>> -
>> - *) SECURITY: CVE-2006-5752 (cve.mitre.org)
>> - mod_status: Fix a possible XSS attack against a site with a
>> public
>> - server-status page and ExtendedStatus enabled, for browsers
>> which
>> - perform charset "detection". Reported by Stefan Esser. [Joe
>> Orton]
>> -
>> - *) SECURITY: CVE-2007-1862 (cve.mitre.org)
>> - mod_mem_cache: Copy headers into longer lived storage; header
>> names and
>> - values could previously point to cleaned up storage. PR 41551.
>> - [Davi Arnaut <davi haxent.com.br>]
>> -
>> *) ApacheMonitor: Fix Windows Vista detection. [Mladen Turk]
>>
>> *) mod_deflate: fix protocol handling in deflate input filter
>>
>
>
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Well... I'm east coast :)
On Aug 30, 2007, at 9:48 AM, Cameron J. Young ((Personal)) wrote:
> Jim,
> Is that EST or PST ??
> Cheers,
> Cameron
>
> -----Original Message-----
> From: Jim Jagielski [mailto:jim@jaguNET.com]
> Sent: Thursday, 30 August 2007 23:02
> To: dev@httpd.apache.org
> Subject: Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
>
> Yes, the CHANGES file will be updated to reflect any
> and all security issues for that release...
>
> On Aug 30, 2007, at 8:38 AM, Joe Orton wrote:
>
>> On Thu, Aug 30, 2007 at 08:31:21AM -0400, Jim Jagielski wrote:
>>> Since a few regressions and other issues popped up the
>>> last go around, I cancelled release of 1.3.38, 2.0.60 and
>>> 2.2.5... I think we are close, *very* close to being at
>>> the point to try this all again.
>>
>> Can we move the SECURITY stuff back up to the top and remove the
>> 2.2.5
>> heading - it would just be confusing to users since 2.2.5 doen't
>> really
>> exist? i.e. below, which adds the CVE name for the autoindex issue
>> too.
>>
>> Index: CHANGES
>> ===================================================================
>> --- CHANGES (revision 571136)
>> +++ CHANGES (working copy)
>> @@ -1,11 +1,37 @@
>> -*-
>> coding: utf-8 -*-
>> Changes with Apache 2.2.6
>>
>> - *) mod_autoindex: Add in Type and Charset options to IndexOptions
>> + *) SECURITY: CVE-2007-4465 (cve.mitre.org)
>> + mod_autoindex: Add in Type and Charset options to IndexOptions
>> directive. This allows the admin to explicitly set the
>> content-type and charset of the generated page.
>> [Jim Jagielski]
>>
>> + *) SECURITY: CVE-2007-3847 (cve.mitre.org)
>> + mod_proxy: Prevent reading past the end of a buffer when
>> parsing
>> + date-related headers. PR 41144.
>> + [Davi Arnaut, Nick Kew]
>> +
>> + *) SECURITY: CVE-2007-1863 (cve.mitre.org)
>> + mod_cache: Prevent a segmentation fault if attributes are
>> listed in a
>> + Cache-Control header without any value.
>> + [Niklas Edmundsson <nikke acc.umu.se>]
>> +
>> + *) SECURITY: CVE-2007-3304 (cve.mitre.org)
>> + prefork, worker, event MPMs: Ensure that the parent process
>> cannot
>> + be forced to kill processes outside its process group.
>> + [Joe Orton, Jim Jagielski]
>> +
>> + *) SECURITY: CVE-2006-5752 (cve.mitre.org)
>> + mod_status: Fix a possible XSS attack against a site with a
>> public
>> + server-status page and ExtendedStatus enabled, for browsers
>> which
>> + perform charset "detection". Reported by Stefan Esser. [Joe
>> Orton]
>> +
>> + *) SECURITY: CVE-2007-1862 (cve.mitre.org)
>> + mod_mem_cache: Copy headers into longer lived storage; header
>> names and
>> + values could previously point to cleaned up storage. PR 41551.
>> + [Davi Arnaut <davi haxent.com.br>]
>> +
>> *) log core: ensure we use a special pool for stderr logging, so
>> that
>> the stderr channel remains valid from the time plog is
>> destroyed,
>> until the time the open_logs hook is called again. [William
>> Rowe]
>> @@ -70,33 +96,6 @@
>> improper merging of the cache lock in vhost config
>> PR 43164 [Eric Covener]
>>
>> -Changes with Apache 2.2.5
>> -
>> - *) SECURITY: CVE-2007-3847 (cve.mitre.org)
>> - mod_proxy: Prevent reading past the end of a buffer when
>> parsing
>> - date-related headers. PR 41144.
>> - [Davi Arnaut, Nick Kew]
>> -
>> - *) SECURITY: CVE-2007-1863 (cve.mitre.org)
>> - mod_cache: Prevent a segmentation fault if attributes are
>> listed in a
>> - Cache-Control header without any value.
>> - [Niklas Edmundsson <nikke acc.umu.se>]
>> -
>> - *) SECURITY: CVE-2007-3304 (cve.mitre.org)
>> - prefork, worker, event MPMs: Ensure that the parent process
>> cannot
>> - be forced to kill processes outside its process group.
>> - [Joe Orton, Jim Jagielski]
>> -
>> - *) SECURITY: CVE-2006-5752 (cve.mitre.org)
>> - mod_status: Fix a possible XSS attack against a site with a
>> public
>> - server-status page and ExtendedStatus enabled, for browsers
>> which
>> - perform charset "detection". Reported by Stefan Esser. [Joe
>> Orton]
>> -
>> - *) SECURITY: CVE-2007-1862 (cve.mitre.org)
>> - mod_mem_cache: Copy headers into longer lived storage; header
>> names and
>> - values could previously point to cleaned up storage. PR 41551.
>> - [Davi Arnaut <davi haxent.com.br>]
>> -
>> *) ApacheMonitor: Fix Windows Vista detection. [Mladen Turk]
>>
>> *) mod_deflate: fix protocol handling in deflate input filter
>>
>
>
RE: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by "Cameron J. Young (Personal)" <ca...@tpg.com.au>.
Jim,
Is that EST or PST ??
Cheers,
Cameron
-----Original Message-----
From: Jim Jagielski [mailto:jim@jaguNET.com]
Sent: Thursday, 30 August 2007 23:02
To: dev@httpd.apache.org
Subject: Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Yes, the CHANGES file will be updated to reflect any
and all security issues for that release...
On Aug 30, 2007, at 8:38 AM, Joe Orton wrote:
> On Thu, Aug 30, 2007 at 08:31:21AM -0400, Jim Jagielski wrote:
>> Since a few regressions and other issues popped up the
>> last go around, I cancelled release of 1.3.38, 2.0.60 and
>> 2.2.5... I think we are close, *very* close to being at
>> the point to try this all again.
>
> Can we move the SECURITY stuff back up to the top and remove the 2.2.5
> heading - it would just be confusing to users since 2.2.5 doen't
> really
> exist? i.e. below, which adds the CVE name for the autoindex issue
> too.
>
> Index: CHANGES
> ===================================================================
> --- CHANGES (revision 571136)
> +++ CHANGES (working copy)
> @@ -1,11 +1,37 @@
> -*-
> coding: utf-8 -*-
> Changes with Apache 2.2.6
>
> - *) mod_autoindex: Add in Type and Charset options to IndexOptions
> + *) SECURITY: CVE-2007-4465 (cve.mitre.org)
> + mod_autoindex: Add in Type and Charset options to IndexOptions
> directive. This allows the admin to explicitly set the
> content-type and charset of the generated page.
> [Jim Jagielski]
>
> + *) SECURITY: CVE-2007-3847 (cve.mitre.org)
> + mod_proxy: Prevent reading past the end of a buffer when parsing
> + date-related headers. PR 41144.
> + [Davi Arnaut, Nick Kew]
> +
> + *) SECURITY: CVE-2007-1863 (cve.mitre.org)
> + mod_cache: Prevent a segmentation fault if attributes are
> listed in a
> + Cache-Control header without any value.
> + [Niklas Edmundsson <nikke acc.umu.se>]
> +
> + *) SECURITY: CVE-2007-3304 (cve.mitre.org)
> + prefork, worker, event MPMs: Ensure that the parent process
> cannot
> + be forced to kill processes outside its process group.
> + [Joe Orton, Jim Jagielski]
> +
> + *) SECURITY: CVE-2006-5752 (cve.mitre.org)
> + mod_status: Fix a possible XSS attack against a site with a
> public
> + server-status page and ExtendedStatus enabled, for browsers
> which
> + perform charset "detection". Reported by Stefan Esser. [Joe
> Orton]
> +
> + *) SECURITY: CVE-2007-1862 (cve.mitre.org)
> + mod_mem_cache: Copy headers into longer lived storage; header
> names and
> + values could previously point to cleaned up storage. PR 41551.
> + [Davi Arnaut <davi haxent.com.br>]
> +
> *) log core: ensure we use a special pool for stderr logging, so
> that
> the stderr channel remains valid from the time plog is
> destroyed,
> until the time the open_logs hook is called again. [William
> Rowe]
> @@ -70,33 +96,6 @@
> improper merging of the cache lock in vhost config
> PR 43164 [Eric Covener]
>
> -Changes with Apache 2.2.5
> -
> - *) SECURITY: CVE-2007-3847 (cve.mitre.org)
> - mod_proxy: Prevent reading past the end of a buffer when parsing
> - date-related headers. PR 41144.
> - [Davi Arnaut, Nick Kew]
> -
> - *) SECURITY: CVE-2007-1863 (cve.mitre.org)
> - mod_cache: Prevent a segmentation fault if attributes are
> listed in a
> - Cache-Control header without any value.
> - [Niklas Edmundsson <nikke acc.umu.se>]
> -
> - *) SECURITY: CVE-2007-3304 (cve.mitre.org)
> - prefork, worker, event MPMs: Ensure that the parent process
> cannot
> - be forced to kill processes outside its process group.
> - [Joe Orton, Jim Jagielski]
> -
> - *) SECURITY: CVE-2006-5752 (cve.mitre.org)
> - mod_status: Fix a possible XSS attack against a site with a
> public
> - server-status page and ExtendedStatus enabled, for browsers
> which
> - perform charset "detection". Reported by Stefan Esser. [Joe
> Orton]
> -
> - *) SECURITY: CVE-2007-1862 (cve.mitre.org)
> - mod_mem_cache: Copy headers into longer lived storage; header
> names and
> - values could previously point to cleaned up storage. PR 41551.
> - [Davi Arnaut <davi haxent.com.br>]
> -
> *) ApacheMonitor: Fix Windows Vista detection. [Mladen Turk]
>
> *) mod_deflate: fix protocol handling in deflate input filter
>
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Erik Abele <er...@codefaktor.de>.
On 01.09.2007, at 13:55, Nick Kew wrote:
> On Sat, 1 Sep 2007 00:53:16 +0200
> Erik Abele <er...@codefaktor.de> wrote:
>
>> And can someone please also update the NOTICE file to carry the new
>> copyright date? We are near to the end of 2007 and the file still
>> says 2006; seems it wasn't touched since we changed all the license
>> headers in July of last year ;-)
>
> Talking of which, a grep finds some more instances of 2006.
> Some interesting instances are ap_release.h
Ohh, yah, good catch!
> and common.xsl
> from whence it propagates to every page of documentation!
Re common.xsl please see the recent discussion on docs@...
Cheers,
Erik
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Nick Kew <ni...@webthing.com>.
On Sat, 1 Sep 2007 00:53:16 +0200
Erik Abele <er...@codefaktor.de> wrote:
> And can someone please also update the NOTICE file to carry the new
> copyright date? We are near to the end of 2007 and the file still
> says 2006; seems it wasn't touched since we changed all the license
> headers in July of last year ;-)
Talking of which, a grep finds some more instances of 2006.
Some interesting instances are ap_release.h, and common.xsl
from whence it propagates to every page of documentation!
I've taken the liberty of updating them in 2.0 and 2.2,
as well as trunk.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Erik Abele <er...@codefaktor.de>.
On 30.08.2007, at 15:02, Jim Jagielski wrote:
> Yes, the CHANGES file will be updated to reflect any
> and all security issues for that release...
And can someone please also update the NOTICE file to carry the new
copyright date? We are near to the end of 2007 and the file still
says 2006; seems it wasn't touched since we changed all the license
headers in July of last year ;-)
Cheers,
Erik
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yes, the CHANGES file will be updated to reflect any
and all security issues for that release...
On Aug 30, 2007, at 8:38 AM, Joe Orton wrote:
> On Thu, Aug 30, 2007 at 08:31:21AM -0400, Jim Jagielski wrote:
>> Since a few regressions and other issues popped up the
>> last go around, I cancelled release of 1.3.38, 2.0.60 and
>> 2.2.5... I think we are close, *very* close to being at
>> the point to try this all again.
>
> Can we move the SECURITY stuff back up to the top and remove the 2.2.5
> heading - it would just be confusing to users since 2.2.5 doen't
> really
> exist? i.e. below, which adds the CVE name for the autoindex issue
> too.
>
> Index: CHANGES
> ===================================================================
> --- CHANGES (revision 571136)
> +++ CHANGES (working copy)
> @@ -1,11 +1,37 @@
> -*-
> coding: utf-8 -*-
> Changes with Apache 2.2.6
>
> - *) mod_autoindex: Add in Type and Charset options to IndexOptions
> + *) SECURITY: CVE-2007-4465 (cve.mitre.org)
> + mod_autoindex: Add in Type and Charset options to IndexOptions
> directive. This allows the admin to explicitly set the
> content-type and charset of the generated page.
> [Jim Jagielski]
>
> + *) SECURITY: CVE-2007-3847 (cve.mitre.org)
> + mod_proxy: Prevent reading past the end of a buffer when parsing
> + date-related headers. PR 41144.
> + [Davi Arnaut, Nick Kew]
> +
> + *) SECURITY: CVE-2007-1863 (cve.mitre.org)
> + mod_cache: Prevent a segmentation fault if attributes are
> listed in a
> + Cache-Control header without any value.
> + [Niklas Edmundsson <nikke acc.umu.se>]
> +
> + *) SECURITY: CVE-2007-3304 (cve.mitre.org)
> + prefork, worker, event MPMs: Ensure that the parent process
> cannot
> + be forced to kill processes outside its process group.
> + [Joe Orton, Jim Jagielski]
> +
> + *) SECURITY: CVE-2006-5752 (cve.mitre.org)
> + mod_status: Fix a possible XSS attack against a site with a
> public
> + server-status page and ExtendedStatus enabled, for browsers
> which
> + perform charset "detection". Reported by Stefan Esser. [Joe
> Orton]
> +
> + *) SECURITY: CVE-2007-1862 (cve.mitre.org)
> + mod_mem_cache: Copy headers into longer lived storage; header
> names and
> + values could previously point to cleaned up storage. PR 41551.
> + [Davi Arnaut <davi haxent.com.br>]
> +
> *) log core: ensure we use a special pool for stderr logging, so
> that
> the stderr channel remains valid from the time plog is
> destroyed,
> until the time the open_logs hook is called again. [William
> Rowe]
> @@ -70,33 +96,6 @@
> improper merging of the cache lock in vhost config
> PR 43164 [Eric Covener]
>
> -Changes with Apache 2.2.5
> -
> - *) SECURITY: CVE-2007-3847 (cve.mitre.org)
> - mod_proxy: Prevent reading past the end of a buffer when parsing
> - date-related headers. PR 41144.
> - [Davi Arnaut, Nick Kew]
> -
> - *) SECURITY: CVE-2007-1863 (cve.mitre.org)
> - mod_cache: Prevent a segmentation fault if attributes are
> listed in a
> - Cache-Control header without any value.
> - [Niklas Edmundsson <nikke acc.umu.se>]
> -
> - *) SECURITY: CVE-2007-3304 (cve.mitre.org)
> - prefork, worker, event MPMs: Ensure that the parent process
> cannot
> - be forced to kill processes outside its process group.
> - [Joe Orton, Jim Jagielski]
> -
> - *) SECURITY: CVE-2006-5752 (cve.mitre.org)
> - mod_status: Fix a possible XSS attack against a site with a
> public
> - server-status page and ExtendedStatus enabled, for browsers
> which
> - perform charset "detection". Reported by Stefan Esser. [Joe
> Orton]
> -
> - *) SECURITY: CVE-2007-1862 (cve.mitre.org)
> - mod_mem_cache: Copy headers into longer lived storage; header
> names and
> - values could previously point to cleaned up storage. PR 41551.
> - [Davi Arnaut <davi haxent.com.br>]
> -
> *) ApacheMonitor: Fix Windows Vista detection. [Mladen Turk]
>
> *) mod_deflate: fix protocol handling in deflate input filter
>
Re: Guess what? Time for 1.3.39, 2.0.61 and 2.2.6 :)
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Aug 30, 2007 at 08:31:21AM -0400, Jim Jagielski wrote:
> Since a few regressions and other issues popped up the
> last go around, I cancelled release of 1.3.38, 2.0.60 and
> 2.2.5... I think we are close, *very* close to being at
> the point to try this all again.
Can we move the SECURITY stuff back up to the top and remove the 2.2.5
heading - it would just be confusing to users since 2.2.5 doen't really
exist? i.e. below, which adds the CVE name for the autoindex issue too.
Index: CHANGES
===================================================================
--- CHANGES (revision 571136)
+++ CHANGES (working copy)
@@ -1,11 +1,37 @@
-*- coding: utf-8 -*-
Changes with Apache 2.2.6
- *) mod_autoindex: Add in Type and Charset options to IndexOptions
+ *) SECURITY: CVE-2007-4465 (cve.mitre.org)
+ mod_autoindex: Add in Type and Charset options to IndexOptions
directive. This allows the admin to explicitly set the
content-type and charset of the generated page.
[Jim Jagielski]
+ *) SECURITY: CVE-2007-3847 (cve.mitre.org)
+ mod_proxy: Prevent reading past the end of a buffer when parsing
+ date-related headers. PR 41144.
+ [Davi Arnaut, Nick Kew]
+
+ *) SECURITY: CVE-2007-1863 (cve.mitre.org)
+ mod_cache: Prevent a segmentation fault if attributes are listed in a
+ Cache-Control header without any value.
+ [Niklas Edmundsson <nikke acc.umu.se>]
+
+ *) SECURITY: CVE-2007-3304 (cve.mitre.org)
+ prefork, worker, event MPMs: Ensure that the parent process cannot
+ be forced to kill processes outside its process group.
+ [Joe Orton, Jim Jagielski]
+
+ *) SECURITY: CVE-2006-5752 (cve.mitre.org)
+ mod_status: Fix a possible XSS attack against a site with a public
+ server-status page and ExtendedStatus enabled, for browsers which
+ perform charset "detection". Reported by Stefan Esser. [Joe Orton]
+
+ *) SECURITY: CVE-2007-1862 (cve.mitre.org)
+ mod_mem_cache: Copy headers into longer lived storage; header names and
+ values could previously point to cleaned up storage. PR 41551.
+ [Davi Arnaut <davi haxent.com.br>]
+
*) log core: ensure we use a special pool for stderr logging, so that
the stderr channel remains valid from the time plog is destroyed,
until the time the open_logs hook is called again. [William Rowe]
@@ -70,33 +96,6 @@
improper merging of the cache lock in vhost config
PR 43164 [Eric Covener]
-Changes with Apache 2.2.5
-
- *) SECURITY: CVE-2007-3847 (cve.mitre.org)
- mod_proxy: Prevent reading past the end of a buffer when parsing
- date-related headers. PR 41144.
- [Davi Arnaut, Nick Kew]
-
- *) SECURITY: CVE-2007-1863 (cve.mitre.org)
- mod_cache: Prevent a segmentation fault if attributes are listed in a
- Cache-Control header without any value.
- [Niklas Edmundsson <nikke acc.umu.se>]
-
- *) SECURITY: CVE-2007-3304 (cve.mitre.org)
- prefork, worker, event MPMs: Ensure that the parent process cannot
- be forced to kill processes outside its process group.
- [Joe Orton, Jim Jagielski]
-
- *) SECURITY: CVE-2006-5752 (cve.mitre.org)
- mod_status: Fix a possible XSS attack against a site with a public
- server-status page and ExtendedStatus enabled, for browsers which
- perform charset "detection". Reported by Stefan Esser. [Joe Orton]
-
- *) SECURITY: CVE-2007-1862 (cve.mitre.org)
- mod_mem_cache: Copy headers into longer lived storage; header names and
- values could previously point to cleaned up storage. PR 41551.
- [Davi Arnaut <davi haxent.com.br>]
-
*) ApacheMonitor: Fix Windows Vista detection. [Mladen Turk]
*) mod_deflate: fix protocol handling in deflate input filter