In theory, we now correctly implement all of the FastCGI protocol, so

there's no reason that request ids wouldn't be matching up.  Until we
see an example of a request id mismatch error that is absolutely not
caused by an error in our parsing of the FastCGI protocol, we should
be able to go back to treating mismatches as errors.

* modules/proxy/mod_proxy_fcgi.c
  (dispatch): Remove #ifdef that turned off treating rid mismatches as
   fatal errors.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/fcgi-proxy-dev@366985 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/modules/proxy/mod_proxy_fcgi.c b/modules/proxy/mod_proxy_fcgi.c
index efa03f07b084ab5d09b726b460e12e521fc66713..c9b0c72f4f1637f1b27c0d03016ccea50202b76c 100644 (file)
--- a/modules/proxy/mod_proxy_fcgi.c
+++ b/modules/proxy/mod_proxy_fcgi.c
@@ -502,10 +502,8 @@ static apr_status_t dispatch(proxy_conn_rec *conn, request_rec *r,
                 ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
                              "proxy: FCGI: Got bogus rid %d, expected %d",
                              rid, request_id);
-#if defined(RID_MISMATCH_IS_TERMINAL_ERROR)
                 rv = APR_EINVAL;
                 break;
-#endif
             }
 
             clen = header[FCGI_HDR_CONTENT_LEN_B1_OFFSET] << 8;