And application hangs for some time.
I confirmed the issue - this is specific to the server implementation: HTTP::Server::PSGI and HTTP::Server::Simple::PSGI. There's no issue with Starman and Twiggy.
Hmm, the server code blocks when it tries to sysread from the socket to read the request headers. Maybe the incognito mode doesn't seem to send the correct EOF marker? Still not sure why it has no issues with Starman and Twiggy though.
I can't reproduce the problem in both anonymous and normal mode using the instructions above. I use Plack 0.9945 and Chrome 12.0.725.0 dev. The server started as HTTP::Server::PSGI.
I use plack 0.997.6 and chrome 11.0.696.34. Normal mode works fine, the problem is only in anonymous mode.
@pstuifzand which host/port were you using and which OS?
Mine is 127.0.0.1:5000 and Chrome 11.0.696.34 beta on Mac OS X.
Plackup starts with the following message "HTTP::Server::PSGI: Accepting connections at http://0:5000/". I'm running Ubuntu 10.10.
This might be related.
@pstuifzand can you try with the latest Plack? If it doesn't reproduce I'd say this is specific to either Mac OS X or Chrome 11 series bug.
I am on Gentoo Linux, so it is not MacOS X related
@koorchik you should've said that first.
I upgraded, but I still can't reproduce.
Maybe taking a look at about:net-internals can shed some light on the matter.
Upgraded Chrome to 12.0.725.0 dev and still seeing this. So this is not specific to Chrome 11 either.
This is what I get with --timeout 5
You can notice that there's a 7 sec delay between the two SOCKET_BYTES_RECEIVED events.
My request looks normal, for as far as I understand it. https://gist.github.com/916575
I something strange, maybe it's important: If I use nc localhost 5000 and send GET / HTTP/1.0, I get the following response:
nc localhost 5000
GET / HTTP/1.0
HTTP/1.0 200 OK
Date: Tue, 12 Apr 2011 22:31:16 GMT
The 0 (zero) instead of Content-Type surely is wrong.
@pstuifzand that is actually a bug in the code by @koorchik in the original post. I edited it (by adding quotes in Content-Type).
Ow, I think the text of the bug report changed while I wasn't looking. Disregard the last comment.
With that fixed I still don't have the problem. Sorry I can't be more helpful.
chrome event info - https://gist.github.com/916627
I got a report saying the same problem with IE9, although not sure if it is technically the same.
Confirmed this with Starlet with one worker (--workers 1).
Chrome anonymous mode and IE9 opens an empty ACK before sending an actual HTTP request, making the ->read_timeout stuck until the timeout (300s). The workaround is to use a short timeout like 0.5 sec.
Haven't reproduced the issue but apparently the fix will be to set O_NONBLOCK on the socket.