Bug #2259
closed
lighttpd does not send a 301 redirect immediately when proxying to Apache
Added by elvanor over 14 years ago.
Updated about 9 years ago.
Description
I am using lighttpd as a proxy to an Apache backend. In MediaWiki if a 301 is issued, the redirect takes 15 seconds to complete. This is because by default Apache's KeepAlive timeout is 15 seconds; so lighttpd waits for the connection to be closed, when it should send the redirect to the client right away.
If I lower the keep alive of Apache, then it takes that number of seconds for the redirect to come to the client (eg, setting the keep alive timeout to 5 seconds makes the redirect take 5 seconds), so the problem is clearly that lighttpd waits until the connection is closed.
A redirect taking 15 seconds is of course problematic.
Note that with a 302, this behavior does not happen.
Tested under vanilla-1.4.28.
Ok, i can reproduce it:
Run a "webserver" to generate 301 responses:
while true; do (echo -en 'HTTP/1.1 301 Moved Permanently\r\nLocation: XYZ\r\nContent-Length: 0\r\n\r\n'; cat) | nc -4 -v -l localhost 8080; echo Connection closed; done
(Press CTRL-D to close an accepted connection)
Lighty config:
proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 8080 ) ) )
- Priority changed from High to Normal
Don´t use "High" if it isn´t a severe bug!
Normaly a Status: 301 + Location headers would be all thats needed. Though a manual link in the body section is for users whose browsers do not support this feature. So we need to wait for the body part.
We do not really care about such users :)
And we certainly have to respect Content-Length: 0.
Btw: it doesn't work with 302 either (as long as it doesn't contain a body).
I think i found the problem, fix will be coming soon.
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset r2770.
- Status changed from Fixed to Reopened
- Target version changed from 1.4.29 to 1.4.33
- % Done changed from 100 to 50
Reopened following a discussion on IRC.
It looks like the next request on the same connection waits for the backend connection to end.
This isn't really a bug in lighttpd, as the (apache) backend should close the connection after it wrote all data; mod_proxy uses HTTP/1.0 and does not send "Connection:" (keep-alive) headers, so the backend (apache) must not use keep-alive connections.
- Target version changed from 1.4.33 to 1.4.34
- Target version changed from 1.4.34 to 1.4.x
todo: close (backend) connection after response body was received, use content-length header
but: shouldn't be needed with HTTP/1.0 connections (which is all that mod_proxy supports) - probably in this case not directly apache's fault but some backend sending connection: keep-alive.
(sane) patches welcome.
- Status changed from Reopened to Fixed
- Target version changed from 1.4.x to 1.4.40
lighttpd mod_proxy will now send explicit Connection: close with requests to backends, so this should no longer be an issue, as the backend Apache will shutdown the write end of its socket, and the lighttpd reverse proxy will get 0-byte read() (EOF), as mod_proxy expects, to signal end of response.
commit f56fe331e5a19debca7312a1e59f08cb7469e3e9
Author: Stefan Bühler <stbuehler@web.de>
Date: Fri Mar 4 19:23:16 2016 +0000
[mod_proxy] use case-insensitive comparision to filter headers, send Connection: Close to backend (fixes #421)
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3093 152afb58-edef-0310-8abb-c4023f1b3aa9
Also available in: Atom
Fix mod_proxy waiting for response even if content-length is 0 (fixes #2259)
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2770 152afb58-edef-0310-8abb-c4023f1b3aa9