HTTP::Server::PSGI hangs when you open it with google chrome anonymous mode

[koorchik]

1. Run psgi application: plackup -e 'sub {return [200, [ "Content-Type" => "text/plain"], ["Hello\n", "World\n"] ]}'
2. Open google chrome anonymous mode (CTRL+SHIFT+N)
3. Go to localhost:5000 and refresh page several time

And application hangs for some time.

[miyagawa]

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.

[miyagawa]

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.

[pstuifzand]

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.

[koorchik]

I use plack 0.997.6 and chrome 11.0.696.34. Normal mode works fine, the problem is only in anonymous mode.

[miyagawa]

@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.

[pstuifzand]

Plackup starts with the following message "HTTP::Server::PSGI: Accepting connections at http://0:5000/". I'm running Ubuntu 10.10.

[miyagawa]

This might be related.
http://code.google.com/p/chromium/issues/detail?id=66622&q=incognito%20socket&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS

[miyagawa]

@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.

[pstuifzand]

I had a similar problem a two weeks ago while working on broken WebSocket Javascript code. After the sockets closed, because of a timeout, it takes some time to be able reuse those sockets. Chrome couldn't open new connections in the meantime. Probably unrelated. Could you be hitting some kind of connection maximum?

[koorchik]

I am on Gentoo Linux, so it is not MacOS X related

[miyagawa]

@koorchik you should've said that first.

[pstuifzand]

I upgraded, but I still can't reproduce.

[pstuifzand]

Maybe taking a look at about:net-internals can shed some light on the matter.

[miyagawa]

Upgraded Chrome to 12.0.725.0 dev and still seeing this. So this is not specific to Chrome 11 either.

[miyagawa]

This is what I get with --timeout 5
https://gist.github.com/916563

You can notice that there's a 7 sec delay between the two SOCKET_BYTES_RECEIVED events.

[pstuifzand]

My request looks normal, for as far as I understand it. https://gist.github.com/916575

[pstuifzand]

I something strange, maybe it's important: If I use nc localhost 5000 and send GET / HTTP/1.0, I get the following response:

HTTP/1.0 200 OK
Date: Tue, 12 Apr 2011 22:31:16 GMT
Server: HTTP::Server::PSGI
0: text/plain
Content-Length: 12

HellonWorldn

The 0 (zero) instead of Content-Type surely is wrong.

[miyagawa]

@pstuifzand that is actually a bug in the code by @koorchik in the original post. I edited it (by adding quotes in Content-Type).

[pstuifzand]

Ow, I think the text of the bug report changed while I wasn't looking. Disregard the last comment.

[pstuifzand]

With that fixed I still don't have the problem. Sorry I can't be more helpful.

[koorchik]

chrome event info - https://gist.github.com/916627

[miyagawa]

I got a report saying the same problem with IE9, although not sure if it is technically the same.

[miyagawa]

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.

@kazuho

[kazuho]

Haven't reproduced the issue but apparently the fix will be to set O_NONBLOCK on the socket.

[sdondley]

This is happening for me even when not in incognito mode.

[sdondley]

One other observation on this. If I switch chrome to another tab, sometimes that is enough to trigger plack to kick over and generate the page. Switching to another tab and then loading a completely different website always generates the page load.

[miyagawa]

Because HTTP::Server::PSGI is a single process web server, it should only be used for a development and testing purpose without multiple users/windows/tabs to open connections. This should be just a known issue and very well can be documented.

[sdondley]

Understood. I'm just going to use Firefox. Though I did lose a lot of time trying to figure out what was wrong with the default Dancer app that uses Plack. I don't quite understand what Plack is though I did buy the $5 book. Working through it. :)