Bug #1178
closedmod_proxy_core + tomcat = hanging requests
Description
i have observed the following with both lighttpd 1854 (current trunk) and 1811.
i'm using mod_proxy_core to connect to a single instance of tomcat 6.0.10 using
the following config:
$HTTP["url"] !~ "^/img/" {
proxy-core.max-pool-size = 20
proxy-core.protocol = "http"
proxy-core.balancer = "sqf"
proxy-core.backends = ( "127.0.0.1:8080" )
}
this seems to work at first glance but about 1 out of 4 responses gets a literal '0' appended
(visible in the browser at the end of page) and the connection hangs - apparently until some timeout is hit.
i played with various settings such as proxy-core.max-pool-size = 1, http11 = disable and also
disabled keep-alive in tomcat entirely (maxKeepAliveRequests = 1). none of my tweaks could make the problem go away, some made it even worse.
i'll have to go back to 1.4.x and mod_proxy for now but would be glad if someone
could look into this...
Updated by Anonymous over 17 years ago
I would suggest to use AJP13 protocol with Tomcat instead of proxying HTTP requests.
At least we've successfully run almost half a year Tomcat with AJP13 with lighty 1.5-x trunk.
-- jtiai
Updated by Anonymous about 17 years ago
We have exactly same problem.
BTW AJP13 seems to work much slower then HTTP proxy.
Updated by stepancheg about 17 years ago
Problem was seen in the last announced version -- r1992.
Updated by moe about 17 years ago
Well, we're not using tomcat anymore (left the java-world, it's all fastcgi now) but I
wonder if this is a bug in the mod_proxy_core http backend or if it's a particular problem
with tomcat.
Is anyone using the http backend for anything other than tomcat (or a servlet engine)?
Do you see the same problem?
It smells like a classic off-by-one bug to me.
Updated by stepancheg about 17 years ago
Oops, trac didn't save my comment. Typing again.
mod_proxy_backend_http does not interpret 304 response properly: it always tries to read http message body. 304 requires response has no message body. So Tomcat does not send either "content-length" or "transfer-encoding: chunked" headers. So mod_proxy_backend_http reads until EOF, i. e. hangs.
I tried to
Updated by stepancheg about 17 years ago
diff again:
--- mod_proxy_backend_http.c.orig 2007-11-12 22:42:14.000000000 +0300
+++ mod_proxy_backend_http.c 2007-11-12 22:23:50.000000000 +0300
@@ -226,38 +226,42 @@
PROXY_STREAM_DECODER_FUNC(proxy_http_stream_decoder) {
proxy_connection *proxy_con = sess->proxy_con;
chunkqueue *in = proxy_con->recv;
chunk *c;
if (in->first == NULL) {
if ((sess->content_length >= 0 && sess->bytes_read == sess->content_length) || in->is_closed) {
sess->is_request_finished = 1;
return HANDLER_FINISHED;
}
return HANDLER_GO_ON;
}
/* parse response headers. */
if (!sess->have_response_headers) {
handler_t rc = proxy_http_parse_response_headers(sess, in);
if (rc != HANDLER_FINISHED) return rc;
}
+
+ if (sess->resp->status == 304) {
+ return HANDLER_FINISHED;
+ }
if (sess->is_chunked) {
return proxy_http_parse_chunked_stream(srv, sess, in, out);
} else {
Updated by stepancheg almost 17 years ago
Is anybody alive there? mod_proxy_backend_http is still broken.
Updated by Anonymous over 16 years ago
I have the same problem with apache and fixed it by setting KeepAlive=off in the Apache configuration (for now).
-- sui
Updated by stbuehler over 16 years ago
- Status changed from New to Fixed
- Resolution set to fixed
Fixed in r2235
Updated by stepancheg over 14 years ago
- Status changed from Fixed to Reopened
Same problem with 204 response code. Patch is trivial:
diff -r 02c80992f79d src/mod_proxy_backend_http.c
--- a/src/mod_proxy_backend_http.c Tue Mar 16 14:59:45 2010 +0300
+++ b/src/mod_proxy_backend_http.c Fri Apr 30 23:13:50 2010 +0400
@@ -108,6 +108,7 @@
switch (sess->resp->status) {
case 205: /* class: header only */
+ case 204:
case 304:
sess->is_request_finished = 1;
}
Updated by gstrauss over 8 years ago
- Description updated (diff)
- Missing in 1.5.x set to Yes
Also available in: Atom