💾 Archived View for bbs.geminispace.org › u › skyjake › 11290 captured on 2024-02-05 at 13:31:06. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
There's no actual redirect involved, though.
Hmm I see... The issue is that with the current auto-prompting method that Lagrange uses, there's nothing further to do with a URL that already includes a query string but to send it to the server. That's why only URLs without a query string can be used with the auto-prompting.
2023-10-29 · 3 months ago
🚀 skyjake [OP/mod...] · Oct 29 at 19:33:
My thinking is that it seems wrong to introduce a feature where the client reacts to a particular URL by removing parts of it (the `!?` query) and offering to replace the query with something else. It would introduce a potential conflict where the app needs to discern whether the URL was opened on a page (needing to respect the query prompting rule) or whether the user typed the triggering query string manually, perhaps as a result of a prompt already having been triggered earlier (so triggering another prompt may not make sense). The current implementation has no such ambiguities.
I'll think on this a little more, though.
@skyjake It looks to me like lagrange is considering the empty query as a special case, while in the gemini protocol itself it is not special -- the empty string is just one possibility for the query string.
🚀 skyjake [OP/mod...] · Oct 30 at 12:31:
I don't think the protocol comes into play here. I thought on this a bit more and came away with the following. The user is applying a behavioral rule for opening a link in their client. Currently in Lagrange it is:
To work with Gemkerkerkruip, the rule would need to be:
The difference may seem subtle, but the first rule is simpler because it is purely additive: A is kept as is. The second rule is more powerful but involves somehow instructing the client about URL B. Implicitly it could be A without the query component, but not necessarily.
I don't really have a problem with the second type of rule, but I prefer the first because of its simplicity and because the client can apply it in a straightforward manner as a result of receiving a 1x status.
I may well expand this feature in Lagrange in the future, but the use case is rather specialized so it's not a high priority.
@skyjake If you think of it as replacing the query component, rather than appending to the URL, doesn't the difference go away? In the protocol, a 10 response does require you to replace the query component, rather than append.
🚀 skyjake [OP/mod...] · Oct 30 at 16:07:
If the auto-prompting feature's purpose is defined as causing the client to emulate the situation where a status 10 response is received after requesting a particular URL, yes, replacing the query component makes sense.
I haven't been thinking of the feature like that, though. In my mind, it's a way for the user to ensure that a chosen URL is never requested without a query string present.
I am a bit uncomfortable with the former interpretation because it makes more assumptions about how the server will behave, and doing so purely on clientside is questionable. Not saying it's bad per se; both of these interpretations rely on certain assumptions about the server/application.
I guess I'm missing something. I just sourcedived to see what's going on, and it seems to me that because of the isEmpty_Range check in postOpenLinkCommand_DocumentWidget_ in ui/documentwidget.c, enabling "assume prompt" on urls with non-empty query does nothing at all. I think I'm suggesting simply deleting that check. The feature then works with gemkerkerkruip (and various other things on my capsule which work similarly). What could it break?
I just realised a subtlety I've been missing in the above -- I'd been assuming that empty query is equivalent to no query, but actually that doesn't seem to be prescribed in the gemini spec (unless I'm missing it?), and RFC 3986 indicates that it only holds if it's explicitly mandated in the scheme spec. Spellbinding actually makes use of this, responding with 10 on no query ([...]/cgi) but not on empty query ([...]/cgi?). It's tricky to use this though -- at least with molly brown, the variables passed to cgi scripts can't differentiate between these two.
🚀 skyjake [OP/mod...] · Nov 02 at 13:40:
I think I'm suggesting simply deleting that check.
It's not quite that simple. If this feature was allowed with URLs that already have a query string, the expected behavior would be that the query string in the URL is pre-filled into the query prompt, so the user can edit it before sending it out. Also, other UI changes would be necessary to enable this behavior for a given link on the page.
It would solve this particular issue with Gemkerkerkruip, I think, although perhaps not in the most elegant way. The user would still get the `!?` in the prompt and would have to overwrite it...
empty query is equivalent to no query
According to RFC 3875 (CGI 1.1), at least in the web world the QUERY_STRING must be set to "" if the query component is missing from the URL. So CGI applications are indeed unable to make a distinction between those two cases.
I also don't think this is currently addressed in the Gemini spec, and did mention some time ago to @solderpunk that it would be nice to have an official companion spec for Gemini server CGI.
As it stands, Gemini applications don't have to use CGI, so they can check directly if a query component is present or not in the request URL and behave differently as needed. (Bubble has several cases of this, for example.)
Gemkerkerkruip — A gaming pick for Saturday: the roguelike text adventure Kerkerkruip by Victor Gijsbers and contributors, ported to Gemini by @mbays. I think there's something fascinating about combining text adventures with roguelikes.
💬 skyjake [mod...] · 12 comments · 2 likes · 2023-10-28 · 3 months ago