Warnings in buildconf on trunk
I see the following autoconf warning when executing buildconf on trunk: rebuilding configure configure.in:406: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:386: AC_USE_SYSTEM_EXTENSIONS is expanded from... configure.in:406: the top level configure.in:406: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS Versions: buildconf: checking installation... buildconf: python version 2.6.6 (ok) buildconf: autoconf version 2.63 (ok) buildconf: libtool version 2.2.6b (ok) The same does not happen with 2.4.x, but I was not able to find the cause. Anybody an idea? Regards Rüdiger
Re: Warnings in buildconf on trunk
On 01.10.2013 09:53, Ruediger Pluem wrote: I see the following autoconf warning when executing buildconf on trunk: rebuilding configure configure.in:406: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:386: AC_USE_SYSTEM_EXTENSIONS is expanded from... configure.in:406: the top level configure.in:406: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS Versions: buildconf: checking installation... buildconf: python version 2.6.6 (ok) buildconf: autoconf version 2.63 (ok) buildconf: libtool version 2.2.6b (ok) The same does not happen with 2.4.x, but I was not able to find the cause. Anybody an idea? Could it be related to http://mail-archives.apache.org/mod_mbox/httpd-cvs/201105.mbox/%3c20110509203750.623fb2388...@eris.apache.org%3E ENOTIME to investigate right now, sorry, but maybe the fix is similar (or the above change is the culprit ...)? Regards, Rainer
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 01/10/2013 05:53, Trevor Perrin wrote: On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 28.09.2013 18:34, Dr Stephen Henson wrote: How about something like: int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd); which can return things like... SSL_CONF_TYPE_INVALID:unrecognised name. SSL_CONF_TYPE_FILE: file name. SSL_CONF_TYPE_DIR:directory name. ... others ... SSL_CONF_TYPE_STR:string with no special meaning. Sounds good, yes. Sounds fine to me. But another wrinkle is occurring to me: We're going to need different ServerInfo files for different certs (since things like Certificate Transparency and TACK will return different data depending on the server's cert/key). The OpenSSL code was written on the assumption of one ServerInfo file per SSL_CTX, so will need a bit of rework. But it's worth discussing what the API should be. There are currently 8 possible key/cert types in OpenSSL (ssl/ssl_locl.h): #define SSL_PKEY_RSA_ENC 0 #define SSL_PKEY_RSA_SIGN 1 #define SSL_PKEY_DSA_SIGN 2 #define SSL_PKEY_DH_RSA 3 #define SSL_PKEY_DH_DSA 4 #define SSL_PKEY_ECC5 #define SSL_PKEY_GOST94 6 #define SSL_PKEY_GOST01 7 I think we'd rather not try to embed OIDs or whatever in the ServerInfo files. Perhaps the ServerInfoFile ConfCmd could be annotated to refer to these identifiers somehow? SSLOpenSSLConfCmd ServerInfoFile_RSA_ENC certs/ServerInfo1.pem SSLOpenSSLConfCmd ServerInfoFile_RSA_SIGN certs/ServerInfo2.pem - or - SSLOpenSSLConfCmd ServerInfoFile 0 certs/ServerInfo1.pem SSLOpenSSLConfCmd ServerInfoFile 1 certs/ServerInfo2.pem Any thoughts?? I'd rather we didn't do that for reasons I'll expand on below. OpenSSL has the concept of the current certificate. That is the last certificate set. So you set certificate foo and then any parameters you set are associated with it until another certificate is set. For OpenSSL 1.0.2 you can set custom chains for each certificate type for example. You couldn't do that before 1.0.2. So ServerInfo would really need an option to set at the SSL_CTX or the SSL level in OpenSSL as you can set different certificates for each SSL structure. It would use the current certificate at the SSL_CTX or SSL level to decide which is affected. That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl IMHO you would need a new directive as there's no support for per-certificate SSL_CONF commands: it wasn't intended to be used like that in its current form. This also runs against what IMHO is a long standing historical problem with the way mod_ssl handles certificates: it hard codes the algorithms used in the source. That means every new algorithm needs mod_ssl code changes to support: ECC for example. Ideally it should be able to send an arbitrary number of certificates and keys to OpenSSL and let it decide what to do with them. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Warnings in buildconf on trunk
On Tue, Oct 01, 2013 at 09:53:25AM +0200, Ruediger Pluem wrote: I see the following autoconf warning when executing buildconf on trunk: rebuilding configure configure.in:406: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:386: AC_USE_SYSTEM_EXTENSIONS is expanded from... configure.in:406: the top level configure.in:406: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS Fixed in r1528032. Regards, Joe
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 01/10/2013 11:15, Dr Stephen Henson wrote: To handle ServerInfo properly in mod_ssl IMHO you would need a new directive as there's no support for per-certificate SSL_CONF commands: it wasn't intended to be used like that in its current form. Though thinking about this some more there *could* be a way to handle per-certificate options for SSL_CONF. At the moment we have some flags setting the context of the commands: currently server or client. We could have an additional one to mean the command is a per-certificate command instead of per-SSL or per-SSL_CTX. That would need more work on the mod_ssl side to add the equivalent commands for each certificate and call them at the appropriate time. Though for just one per-certificate option it would be easier to just have a new directive. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_proxy, oooled backend connections and the keep-alive race condition
On Fri, Aug 02, 2013 at 12:33:58PM +, Plüm, Rüdiger, Vodafone Group wrote: The typical way to solve this today is to know the keepalive timeout of the backend and set ttl for this worker to a value a few seconds below. I just looked at a case where the user is hitting this problem and does already have the ttl keepalive-timeout configured like that; and a few seconds difference is not necessarily enough. The problem is that the prefetch of the 16K request body is making it a lot worse - the worst case is (16K/packet size) * Timeout seconds to complete the prefetch. That's time when the proxy *thinks* the connection is valid but the backend thinks the connection is idle. And in most reverse-proxy cases that prefetch is adding basically no value AFAICT - the backend is a known vintage and probably HTTP/1.1. So... could we make the prefetch stuff configurable away? Regards, Joe
Re: [VOTE] Release mod_fcgid 2.3.8
On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
AW: mod_proxy, oooled backend connections and the keep-alive race condition
-Ursprüngliche Nachricht- Von: Joe Orton Gesendet: Dienstag, 1. Oktober 2013 14:23 An: Plüm, Rüdiger, Vodafone Group Cc: dev@httpd.apache.org Betreff: Re: mod_proxy, oooled backend connections and the keep-alive race condition On Fri, Aug 02, 2013 at 12:33:58PM +, Plüm, Rüdiger, Vodafone Group wrote: The typical way to solve this today is to know the keepalive timeout of the backend and set ttl for this worker to a value a few seconds below. I just looked at a case where the user is hitting this problem and does already have the ttl keepalive-timeout configured like that; and a few seconds difference is not necessarily enough. The problem is that the prefetch of the 16K request body is making it a lot worse - the worst case is (16K/packet size) * Timeout seconds to complete the prefetch. True. That's time when the proxy *thinks* the connection is valid but the backend thinks the connection is idle. And in most reverse-proxy cases that prefetch is adding basically no value AFAICT - the backend is a known vintage and probably HTTP/1.1. So... could we make the prefetch stuff configurable away? IMHO no issue with this. Let's hear what others say. I guess the main point of prefetch was to make better decisions whether to use chunked encoding when sending to the backend. Or provide a CL to the backend when the real client does not. Regards Rüdiger
Re: [VOTE] Release mod_fcgid 2.3.8
I can confirm that this makes 2.3.8 act more like 2.3.7... On Sep 30, 2013, at 8:12 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Sep 30, 2013 at 5:23 AM, Steffen i...@apachelounge.com wrote: Running at AL now 2.3.7 again, all fine again with 1-3 processes instead of the 30+ with 2.3.8. The config live running here and your config for synthetic test is different. And not using fat php processes and max processes is in place. Not any mod_fcgid directives here in a vhost, only in server the commonly used config for php. All vhosts here serving .php, including the default vhost. Running server 2012. IfModule fcgid_module FcgidInitialEnv PHPRC d:/servers/apache/conf/ FcgidInitialEnv PATH d:/servers/apache/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; FcgidInitialEnv SystemRoot C:/Windows FcgidInitialEnv SystemDrive C: FcgidInitialEnv TEMP C:/WINDOWS/Temp FcgidInitialEnv TMP C:/WINDOWS/Temp FcgidInitialEnv windir C:/WINDOWS FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000 FcgidMaxRequestsPerProcess 1000 FcgidMaxProcesses 50 FcgidMaxRequestLen 8131072 # added for z-push iPhone FcgidIOTimeout 7200 FcgidConnectTimeout 180 FcgidBusyTimeout 7200 /IfModule Files ~ \.php$ AddHandler fcgid-script .php FcgidWrapper d:/servers/apache/php/php-cgi.exe .php /Files Hi Steffen, Are you able to try this patch? http://people.apache.org/~trawick/restore-fcgid-2.3.7-process-count-r1.txt This reverts one of the changes in 2.3.8 that affects how soon mod_fcgid will create a new process when one isn't immediately available. With this backed out, my simple testcase uses 11-12 processes like 2.3.7 instead of 20 processes like 2.3.8. TIA! On Monday 30/09/2013 at 01:36, Jeff Trawick wrote: On Sun, Sep 29, 2013 at 5:14 PM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17 �� 192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) So far I've only set up a simple test... Simple perl FastCGI script, ab -n 20 -c 20, default main vhost configuration, this for the vhost: VirtualHost *:8082 FCGIDCmdOptions /home/trawick/myhg/apache/fcgid/apps/altinfo.pl \ InitialEnv VHOST=any \ InitialEnv PERL5LIB=/home/trawick/perl5/lib/perl5 /VirtualHost 2.3.7 grows up to about 12 (vs. max 20 concurrent clients). 2.3.8 grows up to about 20. I got both the fastest and slowest times for 200,000 requests using 2.3.8. Generally I suspect 2.3.7 is slightly faster, but I don't have a good overall summary. If you're using FcgidCmdOptions, I'd recommend using the MaxProcesses parameter to something that your system can handle. Otherwise, see FcgidMaxProcesses and FcgidMaxProcessesPerClass. Regardless of 2.3.7 or 2.3.8. Still, for this simple scenario + configuration, 2.3.7 would have been better (generally not worse performance, uses 40% fewer processes). Different scenarios would have different results, but I think that the common, fat PHP processes would have bigger problems with 2.3.8 if there is no reasonable configured limit on the
Re: mod_proxy, oooled backend connections and the keep-alive race condition
Hi devs,
I was about to propose the following patch to allow mod_proxy_http to flush
all data received from the client to the backend immediatly (as it does
already for response data), based on the env proxy-flushall.
It should address this issue, and in the same time allow protocols like MS
RPC-over-HTTP to work with :
SetEnvIf Request_Method ^RPC_IN_DATA proxy-flushall
The patch does preserve the CL when the client gives one, unless some input
filters have been inserted (DEFLATE...).
In no case, when the env is there, the patch will spool the data, using
chunked encoding when CL was provided but might have change (input_filters
!= proto_input_filters).
Maybe you can give it a chance here...
[patch]
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c(revision 1528080)
+++ modules/proxy/mod_proxy_http.c(working copy)
@@ -244,10 +244,15 @@ static int stream_reqbody_chunked(apr_pool_t *p,
apr_bucket_alloc_t *bucket_alloc = r-connection-bucket_alloc;
apr_bucket_brigade *bb;
apr_bucket *e;
+int flushall = 0;
add_te_chunked(p, bucket_alloc, header_brigade);
terminate_headers(bucket_alloc, header_brigade);
+if (apr_table_get(r-subprocess_env, proxy-flushall)) {
+flushall = 1;
+}
+
while (!APR_BUCKET_IS_EOS(APR_BRIGADE_FIRST(input_brigade)))
{
char chunk_hdr[20]; /* must be here due to transient bucket. */
@@ -305,7 +310,8 @@ static int stream_reqbody_chunked(apr_pool_t *p,
}
/* The request is flushed below this loop with chunk EOS header */
-rv = ap_proxy_pass_brigade(bucket_alloc, r, p_conn, origin, bb, 0);
+rv = ap_proxy_pass_brigade(bucket_alloc, r, p_conn, origin, bb,
+ flushall);
if (rv != OK) {
return rv;
}
@@ -371,6 +377,7 @@ static int stream_reqbody_cl(apr_pool_t *p,
apr_off_t cl_val = 0;
apr_off_t bytes;
apr_off_t bytes_streamed = 0;
+int flushall = 0;
if (old_cl_val) {
char *endstr;
@@ -387,6 +394,10 @@ static int stream_reqbody_cl(apr_pool_t *p,
}
terminate_headers(bucket_alloc, header_brigade);
+if (apr_table_get(r-subprocess_env, proxy-flushall)) {
+flushall = 1;
+}
+
while (!APR_BUCKET_IS_EOS(APR_BRIGADE_FIRST(input_brigade)))
{
apr_brigade_length(input_brigade, 1, bytes);
@@ -450,7 +461,8 @@ static int stream_reqbody_cl(apr_pool_t *p,
}
/* Once we hit EOS, we are ready to flush. */
-rv = ap_proxy_pass_brigade(bucket_alloc, r, p_conn, origin, bb,
seen_eos);
+rv = ap_proxy_pass_brigade(bucket_alloc, r, p_conn, origin, bb,
+ (seen_eos || flushall));
if (rv != OK) {
return rv ;
}
@@ -700,6 +712,7 @@ int ap_proxy_http_request(apr_pool_t *p, request_r
apr_off_t bytes;
int force10, rv;
conn_rec *origin = p_conn-connection;
+int flushall = 0;
if (apr_table_get(r-subprocess_env, force-proxy-request-1.0)) {
if (r-expecting_100) {
@@ -710,6 +723,10 @@ int ap_proxy_http_request(apr_pool_t *p, request_r
force10 = 0;
}
+if (apr_table_get(r-subprocess_env, proxy-flushall)) {
+flushall = 1;
+}
+
header_brigade = apr_brigade_create(p, origin-bucket_alloc);
rv = ap_proxy_create_hdrbrgd(p, header_brigade, r, p_conn,
worker, conf, uri, url, server_portstr,
@@ -822,7 +839,8 @@ int ap_proxy_http_request(apr_pool_t *p, request_r
* (an arbitrary value.)
*/
} while ((bytes_read MAX_MEM_SPOOL - 80)
- !APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(input_brigade)));
+ !APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(input_brigade))
+ !flushall);
/* Use chunked request body encoding or send a content-length body?
*
@@ -876,7 +894,8 @@ int ap_proxy_http_request(apr_pool_t *p, request_r
if (force10
|| (apr_table_get(r-subprocess_env, proxy-sendcl)
!apr_table_get(r-subprocess_env, proxy-sendchunks)
- !apr_table_get(r-subprocess_env,
proxy-sendchunked))) {
+ !apr_table_get(r-subprocess_env, proxy-sendchunked)
+ !flushall)) {
rb_method = RB_SPOOL_CL;
}
else {
@@ -889,7 +908,8 @@ int ap_proxy_http_request(apr_pool_t *p, request_r
}
else if (!force10
(apr_table_get(r-subprocess_env, proxy-sendchunks)
- || apr_table_get(r-subprocess_env,
proxy-sendchunked))
+ || apr_table_get(r-subprocess_env,
proxy-sendchunked)
+ || flushall)
!apr_table_get(r-subprocess_env, proxy-sendcl)) {
rb_method = RB_STREAM_CHUNKED;
}
[/patch]
Regards,
Yann.
On Tue, Oct 1, 2013 at 2:36 PM,
Re: mod_proxy, oooled backend connections and the keep-alive race condition
On Tue, Oct 1, 2013 at 3:39 PM, Yann Ylavic ylavic@gmail.com wrote: It should address this issue, and in the same time allow protocols like MS RPC-over-HTTP to work with : SetEnvIf Request_Method ^RPC_IN_DATA proxy-flushall See PR40029 for RPC-over-HTTP debate, it was finally RESOLVED INVALID, which is not obvious... Sorry if that's off topic though, just to point another side-effect caused by the prefetch. Regards, Yann.
Re: mod_proxy, oooled backend connections and the keep-alive race condition
On Oct 1, 2013, at 8:36 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: -Ursprüngliche Nachricht- Von: Joe Orton Gesendet: Dienstag, 1. Oktober 2013 14:23 An: Plüm, Rüdiger, Vodafone Group Cc: dev@httpd.apache.org Betreff: Re: mod_proxy, oooled backend connections and the keep-alive race condition That's time when the proxy *thinks* the connection is valid but the backend thinks the connection is idle. And in most reverse-proxy cases that prefetch is adding basically no value AFAICT - the backend is a known vintage and probably HTTP/1.1. So... could we make the prefetch stuff configurable away? IMHO no issue with this. Let's hear what others say. +1... fine w/ me I guess the main point of prefetch was to make better decisions whether to use chunked encoding when sending to the backend. Or provide a CL to the backend when the real client does not.
Re: mod_proxy, oooled backend connections and the keep-alive race condition
Hi all, Am 01.10.2013 14:36, schrieb Plüm, Rüdiger, Vodafone Group: That's time when the proxy *thinks* the connection is valid but the backend thinks the connection is idle. And in most reverse-proxy cases that prefetch is adding basically no value AFAICT - the backend is a known vintage and probably HTTP/1.1. So... could we make the prefetch stuff configurable away? IMHO no issue with this. Let's hear what others say. I guess the main point of prefetch was to make better decisions whether to use chunked encoding when sending to the backend. Or provide a CL to the backend when the real client does not. As far as I understand the issue, the main point of prefetch was to fix CVE-2005-2088, a HTTP Request Smuggling attack (see also http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088). This is not an argument against making the prefetch stuff configurable, but if this ever gets implemented, this CVE should definitely needs to be mentioned in the documentation so that users are aware of it. Regards, Micha
Re: mod_proxy, oooled backend connections and the keep-alive race condition
On Tue, Oct 1, 2013 at 4:53 PM, Micha Lenk mi...@lenk.info wrote: As far as I understand the issue, the main point of prefetch was to fix CVE-2005-2088, a HTTP Request Smuggling attack (see also http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088). This is discussed in PR40029 and is not related to HRS, the real fix regarding HRS was about both CL/TE sent by th client ( https://issues.apache.org/bugzilla/show_bug.cgi?id=40029#c4). Regards, Micha
Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
On Thu, Jul 5, 2012 at 7:01 PM, chr...@apache.org wrote:
Author: chrisd
Date: Thu Jul 5 23:01:09 2012
New Revision: 1357986
URL: http://svn.apache.org/viewvc?rev=1357986view=rev
Log:
Avoid internal sub-requests and processing of Location headers when
in FCGI_AUTHORIZER mode, as the mod_fcgid_authenticator(), etc. hook
functions report an error if the script returned a Location header and
redirections are nonsensical in this mode.
Previously, the handle_request_ipc() and handle_request() functions would
examine this header when in FCGI_AUTHORIZER mode and then possibly execute
an internal sub-request, which has no particular use, as its return value
is ignored and its output may conflict with that of the actual content
generation phase.
From the FastCGI spec (6.3):
For Authorizer response status values other than 200 (OK), the Web
server denies access and sends the response status, headers, and content
back to the HTTP client.
I was initially confused when looking at this commit (nothing like
reviewing one year later) wondering if it broke this requirement, but
AFAICT 2.3.7 didn't support the feature anyway, so no regression. (Some
iff statements in this code are what control it.)
Modified:
httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
Modified: httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
URL:
http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c?rev=1357986r1=1357985r2=1357986view=diff
==
--- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c (original)
+++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c Thu Jul 5 23:01:09
2012
@@ -320,6 +320,10 @@ handle_request_ipc(request_rec *r, int r
return cond_status;
}
+if (role == FCGI_AUTHORIZER) {
+return cond_status;
+}
+
/* Check redirect */
location = apr_table_get(r-headers_out, Location);
@@ -347,9 +351,8 @@ handle_request_ipc(request_rec *r, int r
}
/* Now pass to output filter */
-if (role == FCGI_RESPONDER
- (rv = ap_pass_brigade(r-output_filters,
- brigade_stdout)) != APR_SUCCESS) {
+if ((rv = ap_pass_brigade(r-output_filters,
+ brigade_stdout)) != APR_SUCCESS) {
if (!APR_STATUS_IS_ECONNABORTED(rv)) {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, rv, r,
mod_fcgid: ap_pass_brigade failed in
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without it, but even if not I'll share the new one. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without it, but even if not I'll share the new one. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ Steffen, by chance can you test the full revert of r1377398 (and follow-on fixes), at http://people.apache.org/~trawick/revert-r1377398.txt (CR-LF to make your GNU patch happy ;) ) I tested before and after on Windows using a trivial PHP script and php-cgi.exe. I didn't see the issue Steffen saw, but it definitely used a lot fewer processes after reverting. -- Born in Roswell... married an alien... http://emptyhammock.com/
