Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some bug with a combination of $*KERNEL.hardware, slurp, run and Cro #1595

Open
AlexDaniel opened this issue Mar 6, 2018 · 10 comments
Open
Labels

Comments

@AlexDaniel
Copy link
Contributor

AlexDaniel commented Mar 6, 2018

OK here's the golf:

#!/usr/bin/env perl6
use Cro::HTTP::Router;
use Cro::HTTP::Server;

my $host-arch = $*KERNEL.hardware; # NEEDED!

my $application = route {
    get {
        say enter;
        $ = run true; # NEEDED!
        say after;
        content 'text/plain', "Hello!";
    }
}

slurp; # slurps whatever we have on stdin, NEEDED!
my Cro::Service $share = Cro::HTTP::Server.new: :$application,
    :host(0.0.0.0), :port(10001);
$share.start; # kinda NEEDED can't do it without it

sleep

Run it like this:

perl6 frustratable.p6 <<< 'blah stdin'

Now go to http://localhost:10001/, the page will open just fine. You'll see “Hello!” and in the terminal you'll see this:

enter
after

Refresh the page (EDIT: press Ctrl+F5 instead of just F5), and you'll not get a response again (you'll be waiting until it times out). No output in the terminal, nothing.

@AlexDaniel
Copy link
Contributor Author

<timotimo> i get loads and loads of enters and afters
<timotimo> i.e. it keeps working

:(

@AlexDaniel
Copy link
Contributor Author

AlexDaniel commented Mar 6, 2018

FWIW Please contact me if ssh access to the machine where this happens is needed. (I can reproduce on whateverable server and on my laptop, both using Cro 0.7.3 and HEAD-ish rakudo)

@zoffixznet
Copy link
Contributor

zoffixznet commented Mar 6, 2018

What browser are you using?

I can't repro under normal use on 2018.01—refreshing all I want and it works.

However, if I load a page in Firefox and then try to load it in Chrome, it "hangs". Also hangs if I try to do it vice-versa (load in Chrome and then in FF).

Also hangs on second connection if I telnet to it:

$ telnet localhost 10001
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
Content-type: text/plain; charset=utf-8
Content-length: 6

Hello!Connection closed by foreign host.
$ telnet localhost 10001
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0

*no response*

Also hangs on second use with WWW:

$ perl6 -MWWW -e 'say get "http://localhost:10001"'
Hello!
$ perl6 -MWWW -e 'say get "http://localhost:10001"'

*no response*

So sounds like Cro is not happy if it's not getting something it got during previous request. Here's a LiveHTTPHeaders capture of the request from Firefox from refreshing the page (where it works without hangs).

If I replay this via telnet, I get no hang, so just need to golf this to figure out which piece makes it not hang:

http://localhost:10001/

GET / HTTP/1.1
Host: localhost:10001
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 6
----------------------------------------------------------
http://localhost:10001/

GET / HTTP/1.1
Host: localhost:10001
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 6
----------------------------------------------------------
http://localhost:10001/

GET / HTTP/1.1
Host: localhost:10001
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 6

@zoffixznet
Copy link
Contributor

zoffixznet commented Mar 6, 2018

If I replay this via telnet, I get no hang, so just need to golf this

Well, one golf I got it simply the HTTP version; but do browsers even try HTTP/1.0 that it'd get a hang? Probably not the main reason.

No hang with

GET / HTTP/1.1
Host: localhost

Hang:

GET / HTTP/1.0

(Host is mandatory in HTTP/1.1, but isn't in HTTP/1.0, but even if I include it in HTTP/1.0, I get a hang)

@zoffixznet
Copy link
Contributor

but do browsers even try HTTP/1.0

Nope, here's a WireShark dump of a packet that never gets a response to:

GET / HTTP/1.1
Host: localhost:10001
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/28.0.1500.52 Chrome/28.0.1500.52 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

@AlexDaniel
Copy link
Contributor Author

Oh! I know what I'm doing differently! I'm hitting Ctrl+F5 instead of just F5! That's using firefox.

@jnthn
Copy link
Member

jnthn commented Mar 6, 2018

Curious that it requires the run too. I wonder if we can golf Cro out of it completely, by replacing that with some structurally similar hack HTTP server using IO::Socket::Async.

@jnthn
Copy link
Member

jnthn commented Mar 6, 2018

That said, that headers have an impact makes me wonder if it could somehow be a Cro thing, but then the run and, more so, the need to call $*KERNEL.hardware, play into this also, when they really shouldn't make any difference if it's a pure Cro bug.

@AlexDaniel
Copy link
Contributor Author

AlexDaniel commented May 30, 2018

This is still an issue, and the workaround is no longer working :(

(still reproducible with the snippet in the OP)

@AlexDaniel
Copy link
Contributor Author

AlexDaniel commented May 30, 2018

Ah, hm. There are probably two issues. The workaround is working again with MVM_JIT_DISABLE=1. (oops it's more like something about precomp)

AlexDaniel added a commit to Raku/whateverable that referenced this issue Jun 2, 2018
Both changes are a workaround for rakudo/rakudo#1595. This commit
should be reverted later.
JJ pushed a commit to JJ/whateverable that referenced this issue Jun 3, 2018
Both changes are a workaround for rakudo/rakudo#1595. This commit
should be reverted later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants