Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On Thu, Nov 14, 2013 at 07:02:58AM +0100, Kaspar Brand wrote: > On 13.11.2013 15:28, Dr Stephen Henson wrote: > > I can vaguely recall that some of that code is designed to avoid the need to > > enter the private key passphrase more than once by decrypting private keys > > once > > and storing the unencrypted forms in serialised form. > > True, it allows to SIGHUP/SIGUSR1 httpd without having to reenter a > passphrase. But my point is a different one, actually: why do we want to > enable users to protect file-based keys with a pass phrase in the first > place? As the article on the Symantec (formerly Securityfocus) site > says: "It is not only inconvenient, but also gives a false sense of > security." I've also always been a sceptic of this (mis)feature, so I hate to be one to defend it. But demand comes from: a) people who want the ability to do filesystem backups without exposing private keys to the set of admins who can read such backups; or e.g. stick keys on NFS mounts, a similar requirement there. b) people who like or are required to follow "security by checklist" or "security by regulator"; some auditor has "No Plaintext Keys !!!" on the checklist, and so we must not use plaintext keys, no argument. I'm most sceptical of all about (b) as motivation for increasing software complexity, but (a) I can at least appreciate. Regards, Joe
Re: [VOTE] Release Apache httpd 2.2.26 as GA
All looks fine Windows VC10, with APR 1.5.0 and APR-util 1.5.3. -Original Message- From: Jim Jagielski Sent: Wednesday, November 13, 2013 6:03 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Cc: test...@httpd.apache.org Subject: [VOTE] Release Apache httpd 2.2.26 as GA The pre-release test tarballs for Apache httpd 2.2.26 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.2.26 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: releasecheck: autoconf version 2.67 (ok) releasecheck: autoheader version 2.67 (ok) releasecheck: libtool version 2.4.2 (ok) Starting SVN export of apr-1.4.8 to httpd-2.2.26/srclib ... Starting SVN export of apr-util-1.5.2 to httpd-2.2.26/srclib ...
Re: http_filter.c r1524770 open issue?
On Nov 13, 2013, at 6:05 PM, William A. Rowe Jr. wrote: > On Wed, 13 Nov 2013 17:14:15 -0500 > Jim Jagielski wrote: > >> >> On Nov 13, 2013, at 2:25 AM, William A. Rowe Jr. >> wrote: >>> >>> Here we've unset C-L and T-E. but it makes no sense to wait if the >>> origin server has no immediate plan to close the connection. >>> >> >> I cannot grok the above. The RFC itself does not make >> the differentiation between keepalive connections or not. >> So what exactly is the issue? Are you saying we should >> handle keepalive connections in this path differently? >> How is that supported by the spec? > > Keep-alive (implicit in HTTP/1.1 absent a Connection: close header) > is orthogonal to an unknown message body. Think about it :) > > STUFF /thisaction HTTP/1.1 > Transfer-Encoding: x-cleverness > Content-Length: 1000 > The above would not be keptalive. It can't be.
Re: Intent to T&R 2.4.7
I'd like to yes, but I don't want to push 2.4.7 out much longer. There are other things in STATUS, like the event patches which have been running on ASF infra for quite awhile, that I'd like to see in 2.4.7 when we ship. We can save UDS for 2.4.8 and make that a(nother) reason for people to upgrade. On Nov 13, 2013, at 8:27 PM, Daniel Ruggeri wrote: > On 11/13/2013 10:39 AM, Jim Jagielski wrote: >> Now that APR 1.5 is soon-to-be released, we are good for >> a release of 2.4.7. >> >> I propose a T&R next week (I'll RM) and would request >> that people look thru STATUS for some remaining backports. > > Are you hoping to push for UDS in 2.4.7? Seems like a great feature... > > (yes, I'm guilty in not testing out the latest trunk patches and > providing feedback - I had planned to do that last week... and this > week... and probably next week) > > -- > Daniel Ruggeri >
Re: [VOTE] Release Apache httpd 2.2.26 as GA
[X ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. AIX 5.3 xlc v11 - build and startup only (must rebuild 'tester' system.) Had a few things show up again with configure, but excellent grade from IBM compiler: no syntax warnings - at all. p.s. I'll get back to you about the configure "thingies" another time - they have little to so with the apache project itself - imho. :applause: On Thu, Nov 14, 2013 at 2:40 AM, Daniel Ruggeri wrote: > On 11/13/2013 11:03 AM, Jim Jagielski wrote: > > [X] +1: Good to go > > [ ] +0: meh > > [ ] -1: Danger Will Robinson. And why. > Verified on Debian 7.0 "wheezy" w/ openssl 0.9.8 and php 5.3 as > accompaniments > > -- > Daniel Ruggeri > >
windows binaries thread from users@
Had a confused user on users@. Noticed two things. * The download page should say "source" not "Unix source" ** maybe a note telling people that we don't (ncessarily?) produce "windows source" packages anymore * pub/httpd/binaries/win32/README should have a blurb at the top that these are contributed binaries and not part of every release. Any objections / anyone want first crack at either? -- Eric Covener cove...@gmail.com
Re: windows binaries thread from users@
On Thu, Nov 14, 2013 at 9:26 AM, Eric Covener wrote: > Had a confused user on users@. > > Noticed two things. > > * The download page should say "source" not "Unix source" > ** maybe a note telling people that we don't (ncessarily?) produce > "windows source" packages anymore > I'm concerned that we don't have generated .mak files anymore. That's a related puzzle. > * pub/httpd/binaries/win32/README should have a blurb at the top that > these are contributed binaries and not part of every release. > My 2 cents: * Stop highlighting any individual binaries on the download page and instead point to pub/httpd/binaries which has a README that states the policies and expectations which applies to all binaries and then links to the directories for individual platforms. * Remove any existing binaries for any platform as soon as soon as there is a release that fixes any CVE, however trivial, which conceivably could affect the platform of the binary. > > > Any objections / anyone want first crack at either? > > > -- > Eric Covener > cove...@gmail.com > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Intent to T&R 2.4.7
What the heck. STATUS is updated w/ the backport proposal and the patch... On Nov 14, 2013, at 7:46 AM, Jim Jagielski wrote: > I'd like to yes, but I don't want to push 2.4.7 out much > longer. There are other things in STATUS, like the event patches > which have been running on ASF infra for quite awhile, that > I'd like to see in 2.4.7 when we ship. We can save UDS for > 2.4.8 and make that a(nother) reason for people to upgrade. > > On Nov 13, 2013, at 8:27 PM, Daniel Ruggeri wrote: > >> On 11/13/2013 10:39 AM, Jim Jagielski wrote: >>> Now that APR 1.5 is soon-to-be released, we are good for >>> a release of 2.4.7. >>> >>> I propose a T&R next week (I'll RM) and would request >>> that people look thru STATUS for some remaining backports. >> >> Are you hoping to push for UDS in 2.4.7? Seems like a great feature... >> >> (yes, I'm guilty in not testing out the latest trunk patches and >> providing feedback - I had planned to do that last week... and this >> week... and probably next week) >> >> -- >> Daniel Ruggeri >> >
mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R 2.2.6 tomorrow)
I peek this message from another thread and create a new one, since
details may not be relevant in the T&R note.
On 11/12/2013 06:56 PM, William A. Rowe Jr. wrote:
On Tue, 12 Nov 2013 11:48:16 -0500
Jim Jagielski wrote:
I intend to T&R 2.2.26 tomorrow... post now if that's
an issue or problem...
As I mentioned earlier, two additional patches should possibly be
considered for protocol correctness. The first you shepherded into
trunk, so I'm particularly interested in your thoughts on backporting
this, Jim...
http://svn.apache.org/viewvc?view=revision&revision=1524192
http://svn.apache.org/viewvc?view=revision&revision=1524770
(Note that the commit log message is missing patch attribution)
A backport is attached, as best as I've figured from the trunk-modulo-
2.2 code path.
The second is the 100-continue behavior, when proxy-interim-response is
set to RFC. As Yann noted in a very long and winding message thread,
the core http filter is pushing a 100 continue interim status, and then
mod_proxy_http is pushing back yet another interim status response. The
core status response must be suppressed on proxy-interim-response RFC
requests.
It's not clear where that discussion thread has ended up, or whether
there is a usable patch to enforce this behavior. As you had the most
to contribute to that thread, can you give us your thoughts on its
current status, Jim?
Actually the issue I described does not depend on the
proxy-interim-response value: when a (positive) ping is configured for
the worker, mod_proxy_http (via ap_proxy_create_hdrbrgd) will set
r->expecting_100 which will cause the http input filter to push a "100
Continue" to the client, before anything is forwarded (when the request
body is prefetched), whether or not the client expects one (eg. "Expect:
100-continue" or not).
But I agree that the proxy-interim-response == "RFC" is an issue too,
per se.
In fact I don't really see why any "100 Continue" response from the
backend should be forwarded to the client, since the client has already
received one during prefetch (from the http input filter, if expected).
When the (interim) response is about to be forwarded, the request has
already been read (fully), hence the client has nothing more to continue...
Forcing another "100 Continue" here (when proxy-interim-response ==
"RFC") is at least useless (it will be ignored), at worst not rfc
compliant (can a receiver send multiple "100 Continue"? when it has
everything already?).
IMHO, the root issue is that mod_proxy_http cannot be an expectation
proxy with its current implementation (forward all the request, then
forward all the response). It acts more as a server for the client and a
client for the backend, and hence should follow the related RFC parts
(not the ones for an expectation proxy, which I guess is what is
intended by the proxy-interim-response == "RFC").
So the 100-continue with the client should be a client<->proxy only
stuff (controlled by r->expecting_100), and the one with the backend
another proxy<->backend only stuff (with the interim responses being
eaten by the proxy), both should be handled separately.
Below is the patch for ap_proxy_create_hdrbrgd (attached too), but I
think a separate client<->proxy and proxy<->backend handling would be
better, I can try to propose it if you agree.
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 1541907)
+++ modules/proxy/proxy_util.c(working copy)
@@ -3126,7 +3126,7 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
apr_bucket *e;
int do_100_continue;
conn_rec *origin = p_conn->connection;
-const char *fpr1;
+const char *fpr1, *expect;
proxy_dir_conf *dconf = ap_get_module_config(r->per_dir_config,
&proxy_module);
/*
@@ -3227,13 +3227,37 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
);
}
-/* Use HTTP/1.1 100-Continue as quick "HTTP ping" test
- * to backend
+/* Use HTTP/1.1 100-Continue as quick "HTTP ping" test to backend.
+ * If a ping test was already tried with the same request, restore
+ * the original Expect header to avoid using the modified one with
+ * subsequent requests (the new backend may not be ping-able).
*/
+expect = apr_table_get(r->notes, "proxy-ping-expect");
+if (expect == NULL) {
+expect = apr_table_get(r->headers_in, "Expect");
+if (expect != NULL) {
+apr_table_setn(r->notes, "proxy-ping-expect", expect);
+}
+else {
+apr_table_setn(r->notes, "proxy-ping-expect", "\n");
+}
+}
+else if (strcmp(expect, "\n") != 0) {
+apr_table_setn(r->headers_in, "Expect", expect);
+}
+else {
+apr_table_unset(r->headers_in, "Expect");
+expect = NULL;
+}
if (do_100_continue) {
-apr_table_mergen(r->heade
mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R 2.2.6 tomorrow)
I peek this message from another thread and create a new one, since
details may not be relevant in the T&R note.
On 11/12/2013 06:56 PM, William A. Rowe Jr. wrote:
On Tue, 12 Nov 2013 11:48:16 -0500
Jim Jagielski wrote:
I intend to T&R 2.2.26 tomorrow... post now if that's
an issue or problem...
As I mentioned earlier, two additional patches should possibly be
considered for protocol correctness. The first you shepherded into
trunk, so I'm particularly interested in your thoughts on backporting
this, Jim...
http://svn.apache.org/viewvc?view=revision&revision=1524192
http://svn.apache.org/viewvc?view=revision&revision=1524770
(Note that the commit log message is missing patch attribution)
A backport is attached, as best as I've figured from the trunk-modulo-
2.2 code path.
The second is the 100-continue behavior, when proxy-interim-response is
set to RFC. As Yann noted in a very long and winding message thread,
the core http filter is pushing a 100 continue interim status, and then
mod_proxy_http is pushing back yet another interim status response. The
core status response must be suppressed on proxy-interim-response RFC
requests.
It's not clear where that discussion thread has ended up, or whether
there is a usable patch to enforce this behavior. As you had the most
to contribute to that thread, can you give us your thoughts on its
current status, Jim?
Actually the issue I described does not depend on the
proxy-interim-response value: when a (positive) ping is configured for
the worker, mod_proxy_http (via ap_proxy_create_hdrbrgd) will set
r->expecting_100 which will cause the http input filter to push a "100
Continue" to the client, before anything is forwarded (when the request
body is prefetched), whether or not the client expects one (eg. "Expect:
100-continue" or not).
But I agree that the proxy-interim-response == "RFC" is an issue too,
per se.
In fact I don't really see why any "100 Continue" response from the
backend should be forwarded to the client, since the client has already
received one during prefetch (from the http input filter, if expected).
When the (interim) response is about to be forwarded, the request has
already been read (fully), hence the client has nothing more to continue...
Forcing another "100 Continue" here (when proxy-interim-response ==
"RFC") is at least useless (it will be ignored), at worst not rfc
compliant (can a receiver send multiple "100 Continue"? when it has
everything already?).
IMHO, the root issue is that mod_proxy_http cannot be an expectation
proxy with its current implementation (forward all the request, then
forward all the response). It acts more as a server for the client and a
client for the backend, and hence should follow the related RFC parts
(not the ones for an expectation proxy, which I guess is what is
intended by the proxy-interim-response == "RFC").
So the 100-continue with the client should be a client<->proxy only
stuff (controlled by r->expecting_100), and the one with the backend
another proxy<->backend only stuff (with the interim responses being
eaten by the proxy), both should be handled separately.
Below is the patch for ap_proxy_create_hdrbrgd (attached too), but I
think a separate client<->proxy and proxy<->backend handling would be
better, I can try to propose it if you agree.
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 1541907)
+++ modules/proxy/proxy_util.c(working copy)
@@ -3126,7 +3126,7 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
apr_bucket *e;
int do_100_continue;
conn_rec *origin = p_conn->connection;
-const char *fpr1;
+const char *fpr1, *expect;
proxy_dir_conf *dconf = ap_get_module_config(r->per_dir_config,
&proxy_module);
/*
@@ -3227,13 +3227,37 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
);
}
-/* Use HTTP/1.1 100-Continue as quick "HTTP ping" test
- * to backend
+/* Use HTTP/1.1 100-Continue as quick "HTTP ping" test to backend.
+ * If a ping test was already tried with the same request, restore
+ * the original Expect header to avoid using the modified one with
+ * subsequent requests (the new backend may not be ping-able).
*/
+expect = apr_table_get(r->notes, "proxy-ping-expect");
+if (expect == NULL) {
+expect = apr_table_get(r->headers_in, "Expect");
+if (expect != NULL) {
+apr_table_setn(r->notes, "proxy-ping-expect", expect);
+}
+else {
+apr_table_setn(r->notes, "proxy-ping-expect", "\n");
+}
+}
+else if (strcmp(expect, "\n") != 0) {
+apr_table_setn(r->headers_in, "Expect", expect);
+}
+else {
+apr_table_unset(r->headers_in, "Expect");
+expect = NULL;
+}
if (do_100_continue) {
-apr_table_mergen(r->headers_in, "Expect", "100
False positive errno test after call to strtol()
The man page for strtol() indicate that the function can set errno to ERANGE (EINVAL is also possible for some environments). But for the errno check to be valid errno should be set to 0 before the function call. - http://linux.die.net/man/3/strtol I've reviewed all cases of calls to strtol() in httpd and APR code. In some cases no validation is performed after the call. In most cases endptr (the second parameter) is checked against the beginning and/or ending of the string which does not guarantee against numeric overflow. In some cases errno is checked for ERANGE. I've attached a patch for the simplest case, where errno is checked but was not set to 0 before the call. I will consider working up a more extensive patch, if it is desired. BTW, this discussion is not purely theoretical. Erroneous "Invalid ThreadStackSize value: " messages have been witnessed in HP-UX environments. Thanks, Mike Rumph Index: server/mpm_common.c === --- server/mpm_common.c (revision 1542069) +++ server/mpm_common.c (working copy) @@ -389,6 +389,7 @@ return err; } +errno = 0; value = strtol(arg, NULL, 10); if (value < 0 || errno == ERANGE) return apr_pstrcat(cmd->pool, "Invalid MaxMemFree value: ", @@ -408,6 +409,7 @@ return err; } +errno = 0; value = strtol(arg, NULL, 10); if (value < 0 || errno == ERANGE) return apr_pstrcat(cmd->pool, "Invalid ThreadStackSize value: ",
Fwd: [users@httpd] mod_proxy doesn't persist connections to php-fpm
Need a way to stop setting backend->close without breaking other users. FastCGI-specific keyword parameter? envvar? -- Forwarded message -- From: Jeff Trawick Date: Thu, Nov 14, 2013 at 4:26 PM Subject: Re: [users@httpd] mod_proxy doesn't persist connections to php-fpm To: "us...@httpd.apache.org" On Thu, Nov 14, 2013 at 4:12 PM, Chandler, Dean A wrote: > Hi, > > I am trying to run Apache 2.4 web server using mod_proxy > and proxy_fcgi to proxy php requests to the PHP-FPM running on same > machine. I am pretty much using default setup for php-fpm.ini with port at > 9000. My problem is that mod_proxy is closing the connection after every > request is complete so I end up with 1000’s of sockets in TIME_WAIT and > eventually apache quits creating sockets. I am using the following proxy > statement to send requests to the php-fpm process. > Funny... I sent this long explanation to somebody recently with a suggestion on what to try: mod_proxy_fcgi should share mod_proxy's general ability to pool connections to a backend, but there has always been line of code in mod_proxy_fcgi that marks all connections for closure at the end of the request. I just found the commit from 7 years ago that does it: http://svn.apache.org/viewvc?view=revision&revision=383278 That line has subsequently moved around a little and the field changed; it looks like this now: /* XXX Setting close to 0 is a great way to end up with * timeouts at this point, since we lack good ways to manage the * back end fastcgi processes. This should be revisited when we * have a better story on that part of things. */ backend->close = 1; I think the point of the commit message is that: * typically you have small connection capacity in the FastCGI application * typically your Apache configuration has a number of Apache child processes handling client requests In this typical scenario you can easily have a number of connections to the FastCGI application which are ready to be reused but they are owned by specific Apache child processes and the Apache child handling a request may not be the one that already has the connection, and the FastCGI app may not accept more connections until some of the other ones are closed. (I.e., the new request waits for some timeout in the app which allows it to close an existing connection and accept a new one). If you have configured Apache with a very small number of child processes and YOUR-BACKEND has good connection capacity (i.e., will accept many concurrent connections), you could try commenting out that line "backend->close = 1" in the bit of code shown above and see how it works for you. (Don't comment out every occurrence of "backend->close = 1", since the backend connection should be closed after certain types of errors.) Assuming that it works fine, check with netstat to see if the typical number of connections to YOUR-BACKEND decreased any. Reusing the same connections is only effective with a relatively small number of Apache child processes. (I guess you are using Event or Worker MPM?) > > > > >ProxyPass fcgi://127.0.0.1:9000/home/httpbld/htdocs/$1 ttl=30 > keepalive=On connectiontimeout=300 ttl=300 max=128 > > > > > > Below is log file showing connections > > > > > > [Wed Nov 13 11:42:56.176124 2013] [proxy:debug] [pid 225428:tid > 139934623480576] proxy_util.c(2194): [client 220.6.6.158:34023] AH00947: > connected /home/httpbld/htdocs/status.html/status to 127.0.0.1:9000 > > [Wed Nov 13 11:42:56.176159 2013] [proxy:trace2] [pid 225428:tid > 139934623480576] proxy_util.c(2446): FCGI: fam 2 socket created to connect > to 127.0.0.1 > > [Wed Nov 13 11:42:56.176985 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(521): [client 220.6.6.158:34023] Headers > from script 'status': > > [Wed Nov 13 11:42:56.177038 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > X-Powered-By: PHP/5.5.5 > > [Wed Nov 13 11:42:56.177060 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > Expires: Thu, 01 Jan 1970 00:00:00 GMT > > [Wed Nov 13 11:42:56.177071 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > Cache-Control: no-cache, no-store, must-revalidate, max-age=0 > > [Wed Nov 13 11:42:56.177082 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > Content-Type: text/plain > > [Wed Nov 13 11:42:56.177196 2013] [proxy:debug] [pid 225428:tid > 139934623480576] proxy_util.c(2035): AH00943: FCGI: has released connection > for (127.0.0.1) > > > > Please let me know if there is any way to enable reuse of connection to > the php-fpm process. > > > > Thanks, > > Dean.. > -- Born in Roswell... married an alien... http://emptyha
Re: [users@httpd] mod_proxy doesn't persist connections to php-fpm
stop setting it all the time in that particular case? Would a ->notes work? On Nov 14, 2013, at 4:29 PM, Jeff Trawick wrote: > Need a way to stop setting backend->close without breaking other users. > > FastCGI-specific keyword parameter? envvar? > > -- Forwarded message -- > From: Jeff Trawick > Date: Thu, Nov 14, 2013 at 4:26 PM > Subject: Re: [users@httpd] mod_proxy doesn't persist connections to php-fpm > To: "us...@httpd.apache.org" > > > On Thu, Nov 14, 2013 at 4:12 PM, Chandler, Dean A > wrote: > Hi, > > I am trying to run Apache 2.4 web server using mod_proxy and > proxy_fcgi to proxy php requests to the PHP-FPM running on same machine. I > am pretty much using default setup for php-fpm.ini with port at 9000. My > problem is that mod_proxy is closing the connection after every request is > complete so I end up with 1000’s of sockets in TIME_WAIT and eventually > apache quits creating sockets. I am using the following proxy statement to > send requests to the php-fpm process. > > > Funny... I sent this long explanation to somebody recently with a suggestion > on what to try: > > mod_proxy_fcgi should share mod_proxy's general ability to pool connections > to a backend, but there has always been line of code in mod_proxy_fcgi that > marks all connections for closure at the end of the request. I just found > the commit from 7 years ago that does it: > > http://svn.apache.org/viewvc?view=revision&revision=383278 > > That line has subsequently moved around a little and the field changed; it > looks like this now: > > /* XXX Setting close to 0 is a great way to end up with > * timeouts at this point, since we lack good ways to manage the > * back end fastcgi processes. This should be revisited when we > * have a better story on that part of things. */ > backend->close = 1; > > I think the point of the commit message is that: > > * typically you have small connection capacity in the FastCGI application > * typically your Apache configuration has a number of Apache child processes > handling client requests > > In this typical scenario you can easily have a number of connections to the > FastCGI application which are ready to be reused but they are owned by > specific Apache child processes and the Apache child handling a request may > not be the one that already has the connection, and the FastCGI app may not > accept more connections until some of the other ones are closed. (I.e., the > new request waits for some timeout in the app which allows it to close an > existing connection and accept a new one). > > If you have configured Apache with a very small number of child processes and > YOUR-BACKEND has good connection capacity (i.e., will accept many concurrent > connections), you could try commenting out that line "backend->close = 1" in > the bit of code shown above and see how it works for you. (Don't comment out > every occurrence of "backend->close = 1", since the backend connection should > be closed after certain types of errors.) > > Assuming that it works fine, check with netstat to see if the typical number > of connections to YOUR-BACKEND decreased any. > > Reusing the same connections is only effective with a relatively small number > of Apache child processes. (I guess you are using Event or Worker MPM?) > > > > > > > >ProxyPass fcgi://127.0.0.1:9000/home/httpbld/htdocs/$1 ttl=30 > keepalive=On connectiontimeout=300 ttl=300 max=128 > > > > > > Below is log file showing connections > > > > > > [Wed Nov 13 11:42:56.176124 2013] [proxy:debug] [pid 225428:tid > 139934623480576] proxy_util.c(2194): [client 220.6.6.158:34023] AH00947: > connected /home/httpbld/htdocs/status.html/status to 127.0.0.1:9000 > > [Wed Nov 13 11:42:56.176159 2013] [proxy:trace2] [pid 225428:tid > 139934623480576] proxy_util.c(2446): FCGI: fam 2 socket created to connect to > 127.0.0.1 > > [Wed Nov 13 11:42:56.176985 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(521): [client 220.6.6.158:34023] Headers from > script 'status': > > [Wed Nov 13 11:42:56.177038 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > X-Powered-By: PHP/5.5.5 > > [Wed Nov 13 11:42:56.177060 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] Expires: > Thu, 01 Jan 1970 00:00:00 GMT > > [Wed Nov 13 11:42:56.177071 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > Cache-Control: no-cache, no-store, must-revalidate, max-age=0 > > [Wed Nov 13 11:42:56.177082 2013] [proxy_fcgi:trace4] [pid 225428:tid > 139934623480576] util_script.c(522): [client 220.6.6.158:34023] > Content-Type: text/plain > > [Wed Nov 13 11:42:56.177196 2013] [proxy:debug] [pid 225428:tid > 13993462
Re: [VOTE] Release Apache httpd 2.2.26 as GA
On 11/13/2013 9:03 AM, Jim Jagielski wrote: [X] +1: Good to go VC9 x86 & x64 XP & Vista x86 Server 2003 R2 x64 APR 1.4.8/APU 1.5.2 APR 1.5.0/APU 1.5.3 Looks good!
