Comment by 🌆 skyjake
Re: "Scriptonite Lagrange Workarounds"
I was also taking a closer look at the RFC, and this stands out to me (from section 2.4):
When a URI is dereferenced, the components and subcomponents significant to the scheme-specific dereferencing process (if any) must be parsed and separated before the percent-encoded octets within those components can be safely decoded, as otherwise the data may be mistaken for component delimiters.
The key word being "scheme-specific". The Gemini URI scheme does not specify semantics for parameters in the path component. In other words, the path component does not further divide into path and parameter subcomponents in Gemini; it's just a path. Therefore, the client can decode the sub-delim characters if it wants.
I will ensure that [, ], and " always remain encoded in the path component, though, to adhere to the RFC.
2025-08-06 · 9 months ago
6 Later Comments ↓
🛸 bluesman [OP] · 2025-08-06 at 06:09:
Path parameters may not be mentioned in the Gemini spec but I think it's reasonable to assume they would be supported as defined by the RFC. The Gemini spec specifically excludes fragments and userinfo but makes no mention of path/matrix parameters.
I find your choice perplexing given the fact that support basically requires a client to do nothing. I think it's an odd decision that may limit future development (and not just my derided project).
I'll continue to base64 the Scriptonite segment on redirect so it's "just a path".
🌆 skyjake [...] · 2025-08-06 at 10:47:
Gemini is intended to be non-extensible, so I'm cautious to accidentally enable behaviors that are not in line with the specification. I am therefore inclined to make it more difficult to make use of obscure features like path subcomponents.
However, I noticed this in the RFC section 2.2:
URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent
[...]
characters in the reserved set are protected from normalization and are therefore safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI.
This pretty explicitly says not to decode or encode the sub-delims for normalization purposes, so I will adhere to that in the future, which should solve the underlying issue.
🌆 skyjake [...] · 2025-08-06 at 13:16:
@bluesman Are you able to compile Lagrange locally? Would be interesting to know if these changes are sufficient to fix the remaining issues (dev branch):
— https://github.com/skyjake/lagrange/commit/7284f5ee591f781eb911f96e87630c09a8ec64d3
🛸 bluesman [OP] · 2025-08-06 at 13:52:
Looking at GitHub, it appears my best bet would be firing up Ubuntu in VirtualBox or use the Pi 5. (My MacOS laptop is ridiculously constrained when it comes to storage). I can certainly give it a shot when I have some time.
If we could figure out another way to share the binary (mac, windows or linux), I could probably get you an answer right away.
🌆 skyjake [...] · 2025-08-06 at 14:45:
Here is a Linux x86_64 AppImage for testing:
— https://etc.skyjake.fi/lagrange/Lagrange-1.18.7_testing-x86_64.AppImage
🛸 bluesman [OP] · 2025-08-06 at 15:36:
I had to install fuse but then it ran fine on Windows Subsystem for Linux - much quicker than firing up Ubuntu in VirtualBox.
Every issue I was having with the auto-prompt system seems to be fixed. I was a little worried when I saw my "2 + 2" example become "2 %2B 2" in the address bar but it works fine and the copied link is percent-encoded.
Thanks for looking at this and apologies for any consternation.
Original Post
Scriptonite Lagrange Workarounds — I put in workarounds for running Scriptonite in Lagrange. The issue is that Lagrange doesn't preserve certain percent-encoded characters in urls (whether on a page or in a redirect). The fix is to sanitize Scriptonite links coming in and base64 on redirect. The one thing I can't workaround is semicolons. If you want to use them in a pre-populated variable or auto-prompt, the Scriptonite segment must be base64 encoded in advance. That should be rare but there...