Bug #243
closedkeep-alive seems funky with some browsers
Description
I'm not sure what's going on here, so please let me know if additional information is required to diagnose this issue.
I seem to be having an issue with keep-alive and redirects, in v1.4.3. If I make a request that does a redirect, I encounter a significant delay when using IE. Using Firefox I get redirected quickly.
I used curl to try and diagnose the problem, and curl experienced the same delay, and I see the following output (below). If I turn off keep-alive, by setting:
server.max-keep-alive-requests = 0
then the problem goes away. So there seems to be some conflict between keep-alive and some http agents.
* About to connect() to devplp1.looksmart.com port 8000 * Connected to devplp1.looksmart.com (172.17.100.161) port 8000 > GET / HTTP/1.1^M User-Agent: curl/7.11.1 (i386-pc-linux-gnu) libcurl/7.11.1 OpenSSL/0.9.7d ipv6 zlib/1.2.1^M Host: devplp1.looksmart.com:8000^M Pragma: no-cache^M Accept: */*^M ^M < HTTP/1.1 302 Found^M < Transfer-Encoding: chunked^M < Date: Thu, 01 Sep 2005 18:34:25 GMT^M < Content-Type: text/html^M < Set-Cookie: _session_id=e3b89fcf2c2dc3af88f7c91f8c3b4335; path=/; expires=Thu, 01 Sep 2005 19:33:59 GMT^M < Cache-Control: no-cache^M < location: http://devplp1.looksmart.com:8000/security/login^M < Server: lighttpd/1.4.1^M * Ignoring the response-body % Total % Received % Xferd Average Speed Time Curr. Dload Upload Total Current Left Speed * Connection #0 left intact * Issue another request to this URL: 'http://devplp1.looksmart.com:8000/security/login' * Connection 0 seems to be dead! * Closing connection #0 * About to connect() to devplp1.looksmart.com port 8000 * Connected to devplp1.looksmart.com (172.17.100.161) port 8000 > GET /security/login HTTP/1.1^M User-Agent: curl/7.11.1 (i386-pc-linux-gnu) libcurl/7.11.1 OpenSSL/0.9.7d ipv6 zlib/1.2.1^M Host: devplp1.looksmart.com:8000^M Pragma: no-cache^M Accept: */*^M ^M < HTTP/1.1 200 OK^M < Transfer-Encoding: chunked^M < Date: Thu, 01 Sep 2005 18:34:56 GMT^M < Content-Type: text/html^M < Set-Cookie: _session_id=c30a08107914a8c56ddde5f3d95b72c9; path=/; expires=Thu, 01 Sep 2005 19:33:59 GMT^M < Cache-Control: no-cache^M < Server: lighttpd/1.4.1^M ^M100 2238 0 2238 0 0 16217 0 --:--:-- 0:00:00 --:--:-- 870 * Connection #0 left intact * Closing connection #0
-- schoenm
Files
Updated by Anonymous over 19 years ago
I applied the "server.max-keep-alive-requests = 0" patch on 1.4.2. It seemed to solve the IE issue on my cable modem machine, but a connection over satellite seemed to stall IE on redirect. For example, when logging out, the browser would show no change although the server had logged me out and redirected to another web page. Forcing a refresh to any page showed the true state of my login/logout.
-- billkatz
Updated by jan over 19 years ago
- Status changed from New to Assigned
With curl/7.13.1 i can't reproduce it with this simple test case:
<?php
header("Location: http://www.kde.org/");
?>
* About to connect() to localhost port 1025 * Trying 127.0.0.1... * connected * Connected to localhost (127.0.0.1) port 1025 > GET /redirect.php HTTP/1.1 User-Agent: curl/7.13.1 (i386-redhat-linux-gnu) libcurl/7.13.1 OpenSSL/0.9.7f zlib/1.2.2.2 libidn/0.5.15 Host: localhost:1025 Pragma: no-cache Accept: */* < HTTP/1.1 302 Found < Date: Tue, 06 Sep 2005 10:06:39 GMT < X-Secret-Message: 42 < Content-type: text/html < X-Powered-By: PHP/5.1.0b3 < Location: http://www.kde.org/ < Content-Length: 0 < Server: lighttpd/1.4.3 * Connection #0 to host localhost left intact * Closing connection #0
Perhaps curl/7.1.x doens't handle chunked-encoding in 302 requests. Can you try if changeset r690 helps.
Updated by Anonymous over 19 years ago
I checked out and build the head of trunk, and the problem was NOT resolved.
-- schoenm
Updated by Anonymous over 19 years ago
Many other folks on the Ruby on Rails mailing list are reporting the same issue w/ 1.4.x.
Is there any additional info I could provide that would resolve the issue?
-- schoenm
Updated by jan over 19 years ago
I need a strace for the same request from webbrick or apache:
$ strace -tt -s 1024 -p <pid of webbrick>
from a single request.
Updated by Anonymous over 19 years ago
jan,
I wasn't able to get an strace of webrick -- for some reason strace quits as soon as the request is made. I was however, able to confirm that this was NOT an issue with lighttpd1316, and I've attached an strace from that.
Does that help?
-- schoenm
Updated by Anonymous about 19 years ago
Tested with 1.4.4, still an issue.
-- schoenm
Updated by Anonymous about 19 years ago
- Status changed from Fixed to Need Feedback
- Resolution deleted (
fixed)
per jan, this has not yet been fixed.
-- schoenm
Updated by jan about 19 years ago
- Status changed from Need Feedback to Fixed
- Resolution set to fixed
fixed in r721
Updated by Anonymous about 19 years ago
I would like to thank the developers for fixing this (I just confirmed it's fixed in lighttpd 1.4.8).
This specifically was an issue with Ruby on Rails and the Safari browser, which is conforming to spec and waiting for the connection to be closed, instead of just acting on the first packet received from the server. I also hope my little comment here will point others to this fix. Get lighttpd 1.4.8 for Ruby on Rails, you need it for redirects to work quickly on Safari!
-- joost
Updated by Anonymous over 17 years ago
This issue seems to come with PHP at times, at least with PHP CGI 5.2.3, it happens on some setups.
I've been unsuccessful in narrowing it down. I can however explain why it happens for me sometimes.
It has to do with HTTP, and how clients (UAs) know when the server is done with the response. Normally, a Content-Length header is present, and the client can just wait for that amount of bytes to arrive. With dynamic content, however, you don't know how much data you're going to generate until after it's done. That's where Transfer-Encoding comes in, setting the header to "chunked" means that the response is divided into chunks. Each chunk is prefixed with a 4-byte ASCII-representation of the chunk length. (This is in hexadecimal if I remember correctly.)
Had it been chunked, the server could just send "0000" and the client would know that the chunk is empty and the request is done, and it could proceed.
The third method is "Connection: close" which means that the server will close the TCP connection once the request is done, and this is how HTTP is done in HTTP 1.0.
The delay arises when none of these three EOF indication styles is present, and the UA can only guess when the response has been sent, and this is usually done through waiting for the remote host to close the connection.
So, when you get this problem, look at your response headers. If you've got curl available, it'll tell you.
$ curl -Lv http://www.example.com/redirect_test.php [...] * no chunk, no close, no size. Assume close to signal end [...]
-- ludvig ${DOT} ericson ${AT} gmail ${DOT} com
Also available in: Atom