💾 Archived View for bbs.geminispace.org › u › mbays › 18707 captured on 2024-08-31 at 15:58:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-19)
-=-=-=-=-=-=-
Re: "Titan implementation woes: reading early response"
@skyjake Right, thanks. This is what I wanted to do, but it seems the lua wrapper I have to use doesn't support it. Shame. I do feel that the protocol would anyway have been better with a "go ahead" response from the server to indicate that the upload can start, so the client doesn't wastefully start an upload which will be ignored, but it's too late for that.
Jul 20 · 6 weeks ago
Echoing what skyjake said, Rosy Crow sends header and body consecutively without waiting for a "go ahead" from the server. If I recall correctly, I originally tried to implement the protocol "correctly" but found that server behavior was too inconsistent. Some servers won't send that acknowledgement, and trying to account for this in the client introduces needless complexity. It's simpler to just send everything in one go.
🚀 mbays [OP] · Jul 21 at 11:18:
@Addison Thanks. Sending everything in one go does seem to be how the protocol is meant to be implemented (though maybe a short pause before sending the body could make sense). I tried to see how exactly your Opal library is doing it, but it seems the details are hidden in .NET libraries which I don't really want to look into.
Titan implementation woes: reading early response — I'm having problems implementing the client side of the Titan protocol, and I wonder if someone here could help me. We send the URI, then the server either immediately sends a response (normally indicating an error) or waits for us to send the body data before responding. But how do we reliably receive such an early response? It seems we have to start sending, but simultaneously be ready to read a response whenever it might come. I'm pretty...