|
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. |
|||
|
18:41
sena_kun joined
|
|||
| patrickb | Do we want Cro::HTTP::Client connection reuse to be resilient to races of the remote end closing the connection and us reusing it? | 20:00 | |
| I have implemented a retry mechanism for HTTP2 (in a PR). Now I noticed the same failure mode in HTTP1.1 connections. | 20:02 | ||
| And I start to wonder, do we even want to solve this issue in Cro itself? | |||
| In the HTTP1.1 case the failure manifests as "Connection unexpectedly closed before response headers received", which is slightly misleading. | 20:03 | ||
| japhb | patrickb: My historical understanding is that the many closing states of TCP connections were designed for this kind of problem -- knocking out most of the races by ratching towards a truly down connection. | 22:04 | |
| I suspect that HTTP needs similar intelligence ... though I'd be a little surprised if there was no guidance available for that. | 22:05 | ||
| We certainly *don't* want to be confusing the heck out of users with misleading errors. | |||
| When you talk about "reusing" a connection, what exactly is getting reused? Do you just mean continuing to send streams from the same flow down the same pipe? Or are you talking about reusing the connection in some other way? | 22:07 | ||
| patrickb | Sending multiple requests down the same not yet closed tcp connection. | 22:33 | |
| HTTP::Client keeps a cache of open connections and reuses those for new requests. | 22:35 | ||
| github.com/croservices/cro-http/bl...t.pm6#L746 | |||
| Also that's the PR that implements the retry for HTTP2: github.com/croservices/cro-http/pull/187 | 22:36 | ||
| In the HTTP2 case it's not the TCP connection that gets closed, but a GoAway packet of the HTTP2 protocol that's received (that has a sequence number and communicates which requests were processed and which won't be). | 22:38 | ||
| From the quick look I had at the error case at hand it seems that in the HTTP1.1 case it's a simple TCP connection close of the server that signals, well, that the connection is closed. | 22:39 | ||
| Anyways, I'm off to bed. I'll backlog, so feel free to comment further. | 22:40 | ||
|
23:03
sena_kun left
|
|||