Re: event MPM (Was: Re: Planning for 2.4.7 in Oct)
Before we incorporate it... can we have some sense of the impact of the optimization? So far we don't have much data to go on. There is talk of releasing some apr 1.5 enhancements. I'd personally favor adding skip list to apr rather than -util or httpd, since it could be useful core functionality, and 2.0 drops the distinction anyways. On Sep 25, 2013 1:37 PM, "Jim Jagielski" wrote: > Bueller? Bueller? > > On Sep 19, 2013, at 12:17 PM, Jim Jagielski wrote: > > > With the successful running, does anyone wish to add > > some votes to STATUS to allow the backport to be > > approved? :) > > > > On Sep 16, 2013, at 9:27 AM, Jim Jagielski wrote: > > > >> visible if pushed, yes. > >> > >> On Sep 15, 2013, at 2:23 PM, Marion & Christophe JAILLET < > christophe.jail...@wanadoo.fr> wrote: > >> > >>> > >>> Le 15/09/2013 16:30, Rainer Jung a écrit : > I'm pretty sure from those pictures you would not be able to find the > point in time where I switched 2.4.6 and 2.4.7-dev between the servers. > >>> > >>> In other words, does it mean that no special performance improvement > is to be expected ? > >>> > >>> I remember to have read somewhere some numbers showing that the gain > should be visible. (but I can't find the discussion any more...) > >>> > >>> CJ > >>> > >> > > > >
Re: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
On Wed, 25 Sep 2013 17:44:48 +0200 Rainer Jung wrote: > On 25.09.2013 07:33, Kaspar Brand wrote: > > On 23.09.2013 11:17, Joe Orton wrote: > >> On Sun, Sep 22, 2013 at 12:32:23PM +0200, Kaspar Brand wrote: > >>> Feedback on this approach is again very welcome. Increasing the > >>> minimum required OpenSSL version from 0.9.7 to 0.9.8a shouldn't > >>> be of concern, IMO, as 0.9.7 is no longer maintained, and 0.9.8a > >>> was released in October 2005 already. > >> > >> I'd guess this is uncontroversial for trunk, but might be worth > >> flagging up in a separate thread since people did care about 0.9.7 > >> last time we had a poll. Or you could just slip it in and anybody > >> who is not paying attention to dev@ can suffer the consequences ;) > > > > Ok, let's do that then. For the sake of completeness: these are the > > threads started in May 2010 and July 2011, respectively: > > > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3c20100525124551.ga11...@redhat.com%3E > > > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201107.mbox/%3c4e35065d.30...@velox.ch%3E > > > > In the first thread, Joe asked about going straight to 1.0[.0], and > > people were mostly concerned about 0.9.8 (not 0.9.7) at that time. > > See e.g. > > > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3ca40a83c6-5030-4226-a09a-a6393cb6e...@apache.org%3E > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201006.mbox/%3c4c0535a9.10...@kippdata.de%3E > > > > What I put together about two years ago is still true: > > > >> Some more data points: > >> > >> - the last OpenSSL 0.9.6 release (0.9.6m) is from March 2004 > >> > >> - OpenSSL 0.9.8 was released in July 2005 > >> > >> - the last OpenSSL 0.9.7 release (0.9.7m) is from February 2007 > >> > >> - OpenSSL 1.0.0 was released in March 2010 > >> > >> I.e., no one should try to compile trunk against OpenSSL 0.9.6 > >> these days, IMO (and even 0.9.7 isn't really a good idea, as the > >> official releases are no longer maintained). I see no good reason to support 0.9.7 - in fact the user who insists on using this can (with 2.4) likely obtain the 2.4.6 mod_ssl sources and use those in perpetuity. Outdated crypto is more dangerous than no crypto, IMHO. > > Speaking of mod_ssl in 2.4.x, I can hardly imagine that OS vendors > > which consider shipping 2.4 (as opposed to 2.2) would still want to > > compile this against OpenSSL 0.9.7 (even Solaris is now at 1.0.0, > > FYI). > > Yes, Solaris 11 uses 1.0.0, only Solaris 10 is still at 0.9.7. But the > lib is installed under sfw and not directly linked in in the platform > ldap lib or similar. So building and installing a custom ssl build and > using it for httpd is not a real problem, because there won't be > incompatibilities. > > The other OS originally mentioned to still use 0.9.7 was RHEL 4 which > I guess now, 3 years later, is no longer of concern. > > > So, QUESTION: is there anyone who still thinks that going to OpenSSL > > 0.9.8a for trunk (and very likely for 2.4.x, when backporting) is a > > bad idea? If so, please raise your voice. I don't see a 'compatibility' concern; we ensure we won't change how users consume mod_ssl. We promise nothing with respect to 3rd party libraries. Anyone adopting 2.4.x since that .0 release, who didn't also adopt at -minimum- 0.9.8 was a fool who needs a prod to adjust things appropriately.
Re: event MPM (Was: Re: Planning for 2.4.7 in Oct)
Bueller? Bueller? On Sep 19, 2013, at 12:17 PM, Jim Jagielski wrote: > With the successful running, does anyone wish to add > some votes to STATUS to allow the backport to be > approved? :) > > On Sep 16, 2013, at 9:27 AM, Jim Jagielski wrote: > >> visible if pushed, yes. >> >> On Sep 15, 2013, at 2:23 PM, Marion & Christophe JAILLET >> wrote: >> >>> >>> Le 15/09/2013 16:30, Rainer Jung a écrit : I'm pretty sure from those pictures you would not be able to find the point in time where I switched 2.4.6 and 2.4.7-dev between the servers. >>> >>> In other words, does it mean that no special performance improvement is to >>> be expected ? >>> >>> I remember to have read somewhere some numbers showing that the gain should >>> be visible. (but I can't find the discussion any more...) >>> >>> CJ >>> >> >
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On 25/09/2013 06:39, Kaspar Brand wrote:
> On 25.09.2013 04:13, Trevor Perrin wrote:
>> The feature is checked in to the 1.0.2 branch [1], so we'd like to
>> expose it through Apache.
>>
>> The patch is pretty simple. I suppose more tests or docs might be
>> needed (?), which I'm happy to write.
>>
>> Anyways, is this something Apache is interested it? Does the patch
>> look correct? [2]
>
> I'd very much prefer to see this supported via SSLOpenSSLConfCmd
> (http://svn.apache.org/r1421323), and not code this into mod_ssl by
> adding yet another directive. For the authz_file / RFC 5878 stuff, I did
> some experiments at the time, and am attaching a[n untested] patch for
> SSL_CTX_use_serverinfo_file - could you give it a try?
>
> Depending on when exactly you need the SSL_CTX_use_serverinfo_file to
> happen in ssl_engine_init.c, we might have to move around the #ifdef
> HAVE_SSL_CONF_CMD block somewhat, but this shouldn't be a real issue
> (for authz_file, it was necessary/doable).
>
Couple of minor refinements. If you do:
+ {cmd_serverinfo_file, "ServerInfoFile", "serverinfo"},
It gets supported in command line utilities to (like s_server, making it
unnecessesary to code it separately). Also if it is only used for servers you
need something like:
if (!(cctx->flags & SSL_CONF_FLAG_SERVER))
return -2;
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
Since you mentioned RFC 5878, I've attached a patch to issue 55467 which allows third party modules to send and receive custom TLS extensions or supplemental data (which can be used to implement support for RFC 5878), and adds reneg support as well (as some folks only want to send the extensions after the initial handshake). https://issues.apache.org/bugzilla/show_bug.cgi?id=55467 Scott On Sep 24, 2013, at 10:39 PM, Kaspar Brand wrote: > On 25.09.2013 04:13, Trevor Perrin wrote: >> The feature is checked in to the 1.0.2 branch [1], so we'd like to >> expose it through Apache. >> >> The patch is pretty simple. I suppose more tests or docs might be >> needed (?), which I'm happy to write. >> >> Anyways, is this something Apache is interested it? Does the patch >> look correct? [2] > > I'd very much prefer to see this supported via SSLOpenSSLConfCmd > (http://svn.apache.org/r1421323), and not code this into mod_ssl by > adding yet another directive. For the authz_file / RFC 5878 stuff, I did > some experiments at the time, and am attaching a[n untested] patch for > SSL_CTX_use_serverinfo_file - could you give it a try? > > Depending on when exactly you need the SSL_CTX_use_serverinfo_file to > happen in ssl_engine_init.c, we might have to move around the #ifdef > HAVE_SSL_CONF_CMD block somewhat, but this shouldn't be a real issue > (for authz_file, it was necessary/doable). > > Kaspar >
Re: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
On 25.09.2013 07:33, Kaspar Brand wrote: > On 23.09.2013 11:17, Joe Orton wrote: >> On Sun, Sep 22, 2013 at 12:32:23PM +0200, Kaspar Brand wrote: >>> Feedback on this approach is again very welcome. Increasing the minimum >>> required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern, >>> IMO, as 0.9.7 is no longer maintained, and 0.9.8a was released in >>> October 2005 already. >> >> I'd guess this is uncontroversial for trunk, but might be worth flagging >> up in a separate thread since people did care about 0.9.7 last time we >> had a poll. Or you could just slip it in and anybody who is not paying >> attention to dev@ can suffer the consequences ;) > > Ok, let's do that then. For the sake of completeness: these are the > threads started in May 2010 and July 2011, respectively: > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3c20100525124551.ga11...@redhat.com%3E > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201107.mbox/%3c4e35065d.30...@velox.ch%3E > > In the first thread, Joe asked about going straight to 1.0[.0], and > people were mostly concerned about 0.9.8 (not 0.9.7) at that time. See e.g. > > https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3ca40a83c6-5030-4226-a09a-a6393cb6e...@apache.org%3E > https://mail-archives.apache.org/mod_mbox/httpd-dev/201006.mbox/%3c4c0535a9.10...@kippdata.de%3E > > What I put together about two years ago is still true: > >> Some more data points: >> >> - the last OpenSSL 0.9.6 release (0.9.6m) is from March 2004 >> >> - OpenSSL 0.9.8 was released in July 2005 >> >> - the last OpenSSL 0.9.7 release (0.9.7m) is from February 2007 >> >> - OpenSSL 1.0.0 was released in March 2010 >> >> I.e., no one should try to compile trunk against OpenSSL 0.9.6 these >> days, IMO (and even 0.9.7 isn't really a good idea, as the official >> releases are no longer maintained). > > Speaking of mod_ssl in 2.4.x, I can hardly imagine that OS vendors which > consider shipping 2.4 (as opposed to 2.2) would still want to compile > this against OpenSSL 0.9.7 (even Solaris is now at 1.0.0, FYI). Yes, Solaris 11 uses 1.0.0, only Solaris 10 is still at 0.9.7. But the lib is installed under sfw and not directly linked in in the platform ldap lib or similar. So building and installing a custom ssl build and using it for httpd is not a real problem, because there won't be incompatibilities. The other OS originally mentioned to still use 0.9.7 was RHEL 4 which I guess now, 3 years later, is no longer of concern. > So, QUESTION: is there anyone who still thinks that going to OpenSSL > 0.9.8a for trunk (and very likely for 2.4.x, when backporting) is a bad > idea? If so, please raise your voice. Not me. Rainer
Re: [PATCH] proxy API to indicate if connection is potentially reusable (for proxy_fcgi)
On Mon, Sep 23, 2013 at 9:40 AM, Jim Jagielski wrote: > Looks good birthday boy! > On Sep 21, 2013, at 4:06 PM, Jeff Trawick wrote: > > > http://people.apache.org/~trawick/check_proxy_connection_reusable_r1.txt > > > > proxy_fcgi should only turn on AP_FCGI_KEEP_CONN if it is possible to > reuse the connection again. There are several issues to consider in the > proxy connection and worker structures to see if the connection is > potentially reusable. > > > > Is the API in the patch referenced above reasonable? (I'm largely > ignorant of any subtleties around reuse.) > > > > Also, I'm ignoring the fact that conn->close is hard-coded to 1 > elsewhere in mod_proxy_fcgi. Rather than hard code AP_FCGI_KEEP_CONN off > to match, I'd rather let this particular mod_proxy_fcgi code do the right > thing regardless. > > > > TIA! > Thanks for looking, guys! > > > > -- > > Born in Roswell... married an alien... > > http://emptyhammock.com/ > > -- Born in Roswell... married an alien... http://emptyhammock.com/
RE: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
No guys, who have been on dev@ longer then I. Regards Rüdiger From: Yann Ylavic [mailto:ylavic@gmail.com] Sent: Mittwoch, 25. September 2013 13:31 To: dev@httpd.apache.org Subject: Re: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a On Wed, Sep 25, 2013 at 1:03 PM, Plüm, Rüdiger, Vodafone Group mailto:ruediger.pl...@vodafone.com>> wrote: This was less a question to you then to other especially "older" guys here, such that we don't miss anything here :-). Do you mean guys < v0.9.8 ? :p Regards
Re: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
On Wed, Sep 25, 2013 at 1:03 PM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > This was less a question to you then to other especially "older" guys > here, such that we don't miss > anything here :-). > Do you mean guys < v0.9.8 ? :p Regards >
RE: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
> -Original Message- > From: Kaspar Brand [mailto:httpd-dev.2...@velox.ch] > Sent: Mittwoch, 25. September 2013 12:20 > To: dev@httpd.apache.org > Subject: Re: Increasing mod_ssl's minimum required OpenSSL version for > trunk/2.4.x to 0.9.8a > > On 25.09.2013 09:42, Plüm, Rüdiger, Vodafone Group wrote: > > IMHO 0.9.8 seems reasonable for trunk and 2.4. > > More formal question: Can we do this for 2.4 without breaking any > promise? > > Sorry for my somewhat naive question, but I guess you need to explain > more specifically (at least to me) what "promise" you mean in this > context...? Promises we made to our users like keeping the ABI compatible on a stable branch during its lifetime. This was less a question to you then to other especially "older" guys here, such that we don't miss anything here :-). Regards Rüdiger
Re: ProxyPassReverse and regex
On 25 Sep 2013, at 10:06, Thomas Eckert wrote: > I'm facing the problem that I have to use ProxyPassReverse inside a > Just a thought: could you hack a workaround with Header Edit? > In my concrete situation I have a container with a negative > lookahead which I need to have ProxyPassReverse understand somehow. I'm > thinking of patching ProxyPassReverse using the ProxyPassMatch code so it > understands regexps correctly. However, this has surely been considered > before and I'm wondering why it was not put in - after all similar code > exists for ProxyPassMatch. Are there pitfalls which I haven't seen yet ? ProxyPass(Match) applies to the Request, ProxyPassReverse to the Response. From memory and without looking in the code, the missing link is per-request memory of how a regexp was expanded in the ProxyPass so that ProxyPassReverse can apply an equivalent rule. It just requires someone to do the work. If you hack it, you might give some consideration to making an API for the ProxyPassReverse regexp expansion, so output filters like mod_proxy_html can use it. -- Nick Kew
Re: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
On 25.09.2013 09:42, Plüm, Rüdiger, Vodafone Group wrote: > IMHO 0.9.8 seems reasonable for trunk and 2.4. > More formal question: Can we do this for 2.4 without breaking any promise? Sorry for my somewhat naive question, but I guess you need to explain more specifically (at least to me) what "promise" you mean in this context...? Kaspar
ProxyPassReverse and regex
I'm facing the problem that I have to use ProxyPassReverse inside a container, which is not really supported as documented in the last paragrpah at http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse I find the 'workaround' mentioned in the docs quite useless: "The same occurs inside a section, but will probably not work as intended, as ProxyPassReverse will interpret the regexp literally as a path; if needed in this situation, specify the ProxyPassReverse outside the section, or in a separate section." How is this supposed to help me when facing such a situation ? If I need to have ProxyPassReverse understand a regex then it will not do so just because I placed it outside of the container since it *always* understands the path argument as literal string - or did I miss anyhing when looking at the ProxyPassReverse code ? In my concrete situation I have a container with a negative lookahead which I need to have ProxyPassReverse understand somehow. I'm thinking of patching ProxyPassReverse using the ProxyPassMatch code so it understands regexps correctly. However, this has surely been considered before and I'm wondering why it was not put in - after all similar code exists for ProxyPassMatch. Are there pitfalls which I haven't seen yet ? Some time ago I dig into some issues I had with using directives inside a container instead of a container. I remember being told in IRC behaves less like a and more like a internally. Might this be connected to 'ProxyPassReverseMatch' not existing ? Cheers, Thomas
RE: ProxySourceAddress leak
Sounds correct.
Regards
Rüdiger
From: Yann
Sent: Mittwoch, 25. September 2013 10:38
To: dev@httpd.apache.org
Subject: ProxySourceAddress leak
Hi devs,
I suspect a memory leak in the following code/patch related to
ProxySourceAddress.
Since the local_addr is associated with the socket, it should have the same
pool (lifetime), which is conn->scpool and not conn->pool.
The less the socket is reused (disablereuse/is_address_reusable/backend close),
the more the leak is substantial (although not reusing a bound socket to
connect the same backend port can be problematic per se...).
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 1526127)
+++ modules/proxy/proxy_util.c(working copy)
@@ -2572,9 +2572,9 @@ PROXY_DECLARE(int) ap_proxy_connect_backend(const
proxy_function, backend_addr->family,
worker->s->hostname);
if (conf->source_address_set) {
-local_addr = apr_pmemdup(conn->pool, conf->source_address,
+local_addr = apr_pmemdup(conn->scpool, conf->source_address,
sizeof(apr_sockaddr_t));
-local_addr->pool = conn->pool;
+local_addr->pool = conn->scpool;
rv = apr_socket_bind(newsock, local_addr);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, rv, s, APLOGNO(00956)
ProxySourceAddress leak
Hi devs,
I suspect a memory leak in the following code/patch related to
ProxySourceAddress.
Since the local_addr is associated with the socket, it should have the same
pool (lifetime), which is conn->scpool and not conn->pool.
The less the socket is reused (disablereuse/is_address_reusable/backend
close), the more the leak is substantial (although not reusing a bound
socket to connect the same backend port can be problematic per se...).
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 1526127)
+++ modules/proxy/proxy_util.c(working copy)
@@ -2572,9 +2572,9 @@ PROXY_DECLARE(int) ap_proxy_connect_backend(const
proxy_function, backend_addr->family,
worker->s->hostname);
if (conf->source_address_set) {
-local_addr = apr_pmemdup(conn->pool, conf->source_address,
+local_addr = apr_pmemdup(conn->scpool,
conf->source_address,
sizeof(apr_sockaddr_t));
-local_addr->pool = conn->pool;
+local_addr->pool = conn->scpool;
rv = apr_socket_bind(newsock, local_addr);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, rv, s,
APLOGNO(00956)
RE: Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
> -Original Message- > From: Kaspar Brand > Sent: Mittwoch, 25. September 2013 07:34 > To: dev@httpd.apache.org > Subject: Increasing mod_ssl's minimum required OpenSSL version for > trunk/2.4.x to 0.9.8a > > > Speaking of mod_ssl in 2.4.x, I can hardly imagine that OS vendors which > consider shipping 2.4 (as opposed to 2.2) would still want to compile > this against OpenSSL 0.9.7 (even Solaris is now at 1.0.0, FYI). > > So, QUESTION: is there anyone who still thinks that going to OpenSSL > 0.9.8a for trunk (and very likely for 2.4.x, when backporting) is a bad > idea? If so, please raise your voice. > > Kaspar IMHO 0.9.8 seems reasonable for trunk and 2.4. More formal question: Can we do this for 2.4 without breaking any promise? Regards Rüdiger
