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

Open
koorchik opened this Issue Apr 12, 2011 · 24 comments

4 participants

@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
plack member

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
plack member

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
plack member

@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
plack member

@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
plack member

@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
plack member

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

@miyagawa
plack member

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
plack member

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

@miyagawa
plack member

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

@miyagawa
plack member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment