|
Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/ Set by moderator on 18 April 2018. |
|||
| japhb | Sounds wise. :-) | 01:17 | |
|
01:23
lizmat_ joined
01:56
ilbot3 joined
|
|||
| moderator | Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/ | ||
|
13:13
lizmat joined
14:13
FROGGS joined
15:35
lizmat joined
16:48
stmuk joined
17:46
lizmat joined
17:48
FROGGS joined
|
|||
| Geth | cro-core: 7bdd92c805 | (Jonathan Worthington)++ | 2 files Parse authority after concatenation This ensures host, port, and friends are available. |
20:49 | |
|
21:14
lizmat joined
|
|||
| Geth | cro-core: 5caad57ca1 | (Jonathan Worthington)++ | 2 files Correct .add('/'), which wrongly gave a parse fail |
22:25 | |
| jnthn | That moment when you pass a couple of dozen fancy tests, then fail a basic case :P | ||
| japhb | D'oh. | 22:32 | |
| jnthn: Has the WebSocket support been tested under TLS? | |||
| I keep getting X::Cro::HTTP::IncorrectPreface when I try to connect to my server with a wss:// URL | 22:33 | ||
| lizmat wonders how www.foundationdb.org would be a good fit for Cro | |||
| japhb | I suppose looking at github.com/croservices/cro-http/bl...er.pm6#L35 the other problem I can think of might be that it assumes if there's been any incoming packet at all that it has at least 24 bytes in it. | 22:34 | |
| jnthn | japhb: Web socket client or server? | ||
| japhb | Server. | 22:35 | |
| I'm basically doing a Tipsy-like thing right now that I need to run TLS-always. | |||
| And I was starting to wire up the latest-foo websocket | |||
| Right now the code very much follows the Tipsy tutorial in basic structure. | 22:36 | ||
| But Chrome just thinks the WebSocket connection attempt stalls, and on the Cro server side I can see the backtrace from that error. | 22:37 | ||
| jnthn | Um...was the exception actually X::Cro::HTTP2::IncorrectPreface? | 22:38 | |
| (The 2 isn't in what you wrote) | 22:39 | ||
| japhb | Yes, that was me failing to hand-type it. | ||
| Sorry about that | |||
| jnthn | Hmmm...can you trun on CRO_TRACE=1 and gist me the output? | 22:40 | |
| I thought that websocket protocl initialization were tied to the HTTP/1.1 protocol | 22:41 | ||
| japhb | Good question. I need to figure out how to set that envvar inside the docker container. :-) | ||
| jnthn | And while we're going down this path: do you pass a :http option to Cro::HTTP::Server? | 22:42 | |
| japhb | Hold on a sec, checking (been a while since I wrote that) | ||
| http => <1.1 2>, | 22:43 | ||
| jnthn | Hmm, so much for that theory then | ||
| But...the only way to get to HTTP/2 with that configuration should be for ALPN to negotiate it | 22:44 | ||
| japhb | Woah, tracing with a large bundle.js scrolls for a while! | 22:45 | |
| Geth | cro-http: b57a2ff892 | (Jonathan Worthington)++ | lib/Cro/HTTP/Client.pm6 Use Cro::Uri's add for client base-uri feature Means that we now get relative URL resolution correct, rather than the simple cheating concatenation we had prior to this. |
22:47 | |
| japhb | This trace is ~200K. Do you want a piece of it? | 22:48 | |
| (And that's just reloading the page, not even doing anything) | |||
| jnthn | I was wanting the bit where it tried and failed to establish the web socket connection :) | 22:49 | |
| timotimo | .o( i wonder if i should get the hexdumper a little performance pass some time ) | 22:50 | |
| jnthn | Maybe if you just stop the app then restart it, it will try to reconnect the socket? | ||
| japhb | OK, I think I've managed to capture that | 22:53 | |
| gisting | |||
| gist.github.com/japhb/ad6e1d415a80...caee3736c9 | 22:57 | ||
| Sheesh, that was a pain | 22:58 | ||
| jnthn | huh...wow, it really is feeding a HTTP/1.1 request header through the HTTP/2 pipeline...but why?! | 23:01 | |
| Surely Chrome can't be negotiating HTTP/2 and then trying to use the connection for a websocket? | |||
| If you configure it as :http<1.1> I'm guessing the problem goes away? | 23:04 | ||
| japhb | Let me check. | 23:07 | |
| Yup, totally worked like a charm | 23:09 | ||
| jnthn | OK. I'm still *really* curious what on earth is happening, though. I should also probably be sleeping. :-) | 23:10 | |
| Will try and repro it another day :) | 23:11 | ||
| 'night o/ | |||
| japhb | Feel free to sleep, I have a workaround for now. :-) | ||
| It's Chrome 64 on this machine, FWIW | |||
| Good night! | |||
| timotimo | chrometendo sixtyfour! | 23:12 | |
| japhb | Question for tomorrow: Is there a way to tell Cro not to trace certain routes, or at least not trace the responses past the initial header, even if CRO_TRACE is true? The "large downloads spam the trace" problem gets a bit annoying, especially since I'm not terribly worried about static blob serving being broken. :-( | 23:52 | |
| timotimo | for now i'd recommend serving static assets with a different webserver, perhaps just a second cro instance of the same app | 23:53 | |
| japhb | timotimo: Hmm, I wonder how single origin rules fit with that ... in any case, I can wait on this one until tomorrow. :-) | 23:56 | |
| timotimo | OK, put the cro app behind a reverse proxy, then :) | 23:58 | |
| that's how web apps usually get deployed anyway if my tiny shred of devops knowledge/experience is to be believed | |||