|
Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
| patrickb | doing `timeout => Cro::HTTP::Client::Policy::Timeout.new(total => Inf, :body(Inf), :connection(Inf), :headers(60), :total(Inf))` worked | 00:11 | |
| jnthnwrthngtn | Ah, right, yes, Inf sets the overall budget | ||
| Maybe it gets a more useful trace | 00:12 | ||
| patrickb | Still waiting. But it's kinda strange. Without CRO_TRACE the thing nearly instantly throws the error. With tracing it fills the console for a few seconds, stops with Cro::TLS::Connector DONE and then hangs for a minute | 00:14 | |
| jnthnwrthngtn | Is there a reset stream frame before the DONE? | ||
| patrickb | Searching through the log for "reset" yields nothing. | 00:15 | |
| jnthnwrthngtn | Hm. I think there's a filter option for CRO_TRACE (I forget the env var) that lets you only get the HTTP bits, which may be a bit less verbose and thus introduce less timing distortions | 00:17 | |
| Sleep time for me, 'night | |||
| patrickb | Thanks so far and sleep well! | ||
|
00:46
patrickb left
11:17
xinming__ left
11:18
xinming__ joined
16:00
patrickb joined
|
|||
| patrickb | o/ | 16:06 | |
| I've had another look at the cro client error. I noticed that when specifying the http version, the ConnectionConditional is gone, and the trace output is then a bit more telling. | 16:08 | ||
| paste.sr.ht/~patrickb/8940f800103c...35a66a2c47 | |||
| Still looks like a pretty sane http2 connection though. | |||
| Thare are no responses in the trace. So unsure how helpful it will be. | 16:10 | ||
| Roughly adding up the transmitted bytes indicates, that the cro managed to upload the 1.7MB file entirely and only afterwards hangs. | 16:11 | ||
| Given this is TCP, I'd guess that cro wouldn't continue happily uploading more bytes when the remote end doesn't answer anymore. So I suspect it goes wrong when closing the connection, not during transmission. | 16:14 | ||
| (But then the "Stream reset by the server" error is still not there when tracing, it just infini hangs, so the trace output might not be representative of the actual problem.) | 16:16 | ||
| I'm not mistaken that tcpdump can't be of much use as HTTP2 is only talked via TLS which I won't be able to look into. That makes directly comparing what curl talks vs what cro does difficult. | 16:18 | ||
| Have to leave for a bit... | |||
|
16:25
rypervenche left
16:32
rypervenche joined
16:59
xinming__ left
17:01
xinming__ joined
20:33
Xliff joined
|
|||
| Xliff | \o | 20:33 | |
| m: my $a; without $a { say 'Unset' } else { 'Set' } | 20:34 | ||
| lizmat | hmmm.. appears camelia is not here | 20:42 | |
| patrickb | is it possible to make cro tls output the session keys? Would allow wiresharking the connection. | 21:17 | |
|
21:23
nine joined
|
|||
| patrickb | The functionality is in SSL_CTX_set_keylog_callback and not yet exposed. | 21:41 | |
| Woot! It works. I can now look at the HTTP2 traffic of cro in Wireshark. How much that'll help, we'll see. | 22:51 | ||
| japhb | Now that's a recipe I'd like to see; I had to implement non-TLS connections for my WebSocket code to be able to Wireshark deeply (WebSocket is HTTP/1.1-only, so that works). I didn't realize there was a way to extract the keys and provide them to Wireshark. | 23:06 | |
| patrickb | www.openssl.org/docs/man1.1.1/man3...lback.html < that's the thing to use. Given there is interest, I guess I'll do a set of PRs. | 23:16 | |
| everything.curl.dev/usingcurl/tls/sslkeylogfile | |||
| japhb | PR++ | 23:44 | |