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