Project

General

Profile

Actions

Bug #243

closed

keep-alive seems funky with some browsers

Added by Anonymous over 18 years ago. Updated over 16 years ago.

Status:
Fixed
Priority:
Urgent
Category:
core
Target version:
ASK QUESTIONS IN Forums:

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

lightty1316.strace (11.6 KB) lightty1316.strace strace of 302 request to lighttpd1316, which does NOT exhibit this bug -- schoenm Anonymous, 2005-09-09 18:59
lightty144.strace (28.6 KB) lightty144.strace strace showing problem w/ 1.4.4 -- schoenm Anonymous, 2005-09-21 08:23
Actions #1

Updated by Anonymous over 18 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

Actions #2

Updated by jan over 18 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.

Actions #3

Updated by Anonymous over 18 years ago

I checked out and build the head of trunk, and the problem was NOT resolved.

-- schoenm

Actions #4

Updated by Anonymous over 18 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

Actions #5

Updated by jan over 18 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.

Actions #6

Updated by Anonymous over 18 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

Actions #7

Updated by Anonymous over 18 years ago

Tested with 1.4.4, still an issue.

-- schoenm

Actions #8

Updated by Anonymous over 18 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (fixed)

per jan, this has not yet been fixed.

-- schoenm

Actions #9

Updated by jan over 18 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to fixed

fixed in r721

Actions #10

Updated by Anonymous over 18 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

Actions #11

Updated by Anonymous over 16 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

Actions

Also available in: Atom