💾 Archived View for bbs.geminispace.org › u › clseibold › 12389 captured on 2023-12-28 at 17:50:54. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "I saw a comment by @clseibold earlier (hope I spelled that..."
@dimkr My point wasn't really whether that was good or not, but that it's how the spec was designed. Stream-like handling is optional in the spec. That's how it was designed.
The spec isn't all-encompasing - a lot of times it allows for *optional things.* A browser can support streaming, it can support different filetypes, it can even display things differently than other clients (headings in lagrange look very different from other browsers, so I make sure to tailor my headings for lagrange first).
How certificates behave is a completely different thing from supporting streaming, imo, so I think it is a false comparison. However, I believe certificates are optional in the spec too.
Peronally, I would require that all clients need to *support* TCP Keep Alive packets when they are used (and I bet many clients already do this), and then the problem we discussed about misbehaving clients would basically be fixed.
Update: Yes, I was correct. Client certificates are completely optional in the spec:
Basic clients may also choose not to support client-certificate authentication, in which case only four distinct status handling routines are required (for statuses beginning with 1, 2, 3 or a combined 4-or-5).
Also from the spec, notice how it's **optional**:
Note that clients are not obligated to wait until the server closes the connection to begin handling the response. This is shown above only for simplicity/clarity, to emphasise that responsibility for closing the connection under typical conditions lies with the server and that the connection should be closed immediately after the completion of the response body.
For example, some capsules have links that align nicely in Lagrange, and Station expects a client certificate for / although it's /join that returns 60 (Lagrange defaults to certificates for /, so it "just works").
The way I see it is this: There's nothing that says that clients cannot use certificates on links that don't request a certificate. Whetehr station expects a client cert for / or /join isn't a client problem, because the client is allowed to use certs on pages that don't request certs, and to lagrange, / encompasses /join.
Which means this is a server problem, not a client problem, because a **server** can only expect a cert to be used on the pages they are requested for.
So it should be reported to the server maintainer/developer, not the client developer, imo.
Dec 06 · 3 weeks ago
🚀 clseibold · Dec 06 at 17:20:
@dimkr Btw, and @skyjake can correct me on this if I'm wrong, but I'm pretty sure lagrange used to only enable certificates on the specific page (like "/join") when that page requested it (and the user enabled the cert from there), rather than always putting it on /. And if I recall correctly, it was the server developers (including me) who didn't realize that we couldn't expect certs on "/" when we only sent the request on "/join" (or "/register").
I ended up fixing this for some of my AuraGem stuff by using "/?register" instead, so that the client cert request always happens on "/", but not all servers fixed this problem, so clients have to adapt to the servers.
So I think the history is actually the opposite - servers started expecting cert requests on subpages to be working for the whole capsule, and clients had to adapt to make this work, instead of the other way around.
I specifically remember running into this problem with one of my AuraGem services, and so I had to fix it on my server, because it was a server bug, not a client bug.
Yes you are correct about the history @clseibold.
This reminds me I should use the "/?register" solution myself in Bubble, because having an actual "Create Account" UI action beats the current "just activate a certificate but please only at the root".
@clseibold @skyjake This history shows how much "wiggle room" the spec has, allowing clients to behave very differently from each other, until clients and servers achieve some status quo not mandated by the spec. I know that my client (and probably many others) doesn't support "chat" because it previews the document during download but shows the prompt that allows you to navigate to a link only when transfer is finished.
🚀 clseibold · Dec 07 at 17:35:
@dimkr I agree that the spec has quite a bit of wiggle room. However, I think the situation with where certs are activated is just an oversight in the spec. One could fix this by just saying under the client certs sections that "A server can only expect a client cert to be activated under the path in which the client cert request status code was sent" or something along those lines.
Lots of clients don't support streaming gemtext in general because it was marked optional. I think the best solution for this is to just go with Solderpunk's idea written in the article I linked ("A vision for Gemini applications") - I can create a chat terminal program specifically for AuraGem Live Chat.
I saw a comment by @clseibold earlier (hope I spelled that right) talking about streaming audio capabilities in mobile Gemini clients. I can't seem to find the post anymore, but it got me thinking about whether Opal (the client library that Rosy Crow uses to do it's Gemini stuff) can support that. [https link] Currently it does not support that, because the entire response is read all at once into a buffer. Thinking about this a while, I of course arrived at the classic conclusion that...