Skip message-body with HTTP 304 responses and mod_proxy_fcgi with no conn reuse.
Background: https://bz.apache.org/bugzilla/show_bug.cgi?id=59838
This commit should be an improvement for http://svn.apache.org/r1752347, in which
I tried to resolve a long standing issue with mod_proxy_fcgi: when a FCGI backend
returns a response that will become a HTTP 304, mod_proxy_fcgi forces a break
in the request processing ending up in reading the remaining bytes (for example
the message-body) and trying to intepret them as a FCGI header. This would cause
a error and a weird behavior:
1) HTTP 304 response flushed to the client correctly.
2) HTTP 503 logged in the access_log plus other bogus errors in the error_log.
I tried to separate the behavior when connection reuse is set or not, to eliminate
unnecessary latency in the latter case (which is the default).
I tested the change with and without connection reuse successfully, but feedback is
really welcome. If nobody will have anything against it I'll then proceed to update
my 2.4.x backport proposal.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1754732 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/modules/proxy/mod_proxy_fcgi.c b/modules/proxy/mod_proxy_fcgi.c
index 2a760fc..1bdd200 100644
--- a/modules/proxy/mod_proxy_fcgi.c
+++ b/modules/proxy/mod_proxy_fcgi.c
@@ -305,7 +305,7 @@
for (i = 0; i < envarr->nelts; ++i) {
ap_log_rerror(APLOG_MARK, APLOG_TRACE8, 0, r, APLOGNO(01062)
"sending env var '%s' value '%s'",
- elts[i].key, elts[i].val);
+ elts[i].key, elts[i].valq);
}
}
@@ -661,14 +661,26 @@
break;
}
else if (status == HTTP_NOT_MODIFIED) {
- /* The 304 response MUST NOT contain
- * a message-body, ignore it.
- * The break is not added since there might
- * be more bytes to read from the FCGI
- * connection. Even if the message-body is
- * ignored we want to avoid subsequent
- * bogus reads. */
+ /* A 304 response MUST NOT contain
+ * a message-body, so we must ignore it but
+ * some extra steps needs to be taken to
+ * avoid inconsistencies.
+ * The break is not added with connection
+ * reuse set since there might be more bytes
+ * to read from the FCGI connection,
+ * like the message-body, that would trigger
+ * subsequent bogus reads (for example
+ * the start of the message-body
+ * interpreted as FCGI header).
+ * With connecton reuse disabled (default)
+ * we can safely break and force the end
+ * of the FCGI processing phase since the
+ * connection will be cleaned up later on. */
ignore_body = 1;
+ if (conn->close) {
+ done = 1;
+ break;
+ }
}
else {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01070)
