local gemtext links are parsed as absolute url if the query string contains a colon #226
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#226
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
I am currently writing a CGI gateway for the Nex protocol and am using links with the format
=> nex.php?nex://host/path
which works in e.g. Lagrange and Amfora, however in bombadillo it is parsed as a URL since nex.php?nex: is taken as the protocol prefix. I assume it should consider the string after the ? as a plain string that does not affect the url so that it would parse it as a relative path for the current url. The error message is no host found nex.php, so I am not completely sure how it is parsed.
gemini://gemini.lehmann.cx/cgi-bin/nex.php
Upon looking at this I realized I built to a different spec (rfc 2396) for Generic URI than was later landed on by gemini. This means you did find something that can be considered a bug. Honestly, I dont really update this application much anymore and will likely not get to it any time soon. I will keep the issue open and possibly return to it at some point in the future. I would venture to guess that if you percent encode the querystring that it would work fine in bombadillo as well. This doesn't solve your problem, assuming you dont want to change your markup... but I figured I'd mention it.
Bombadillo is significantly more old school in its goals and design than the others: they are gemini clients. Bombadillo is a gopher client with some support for gemini. That said, if I end up doing any work in this client in the future I will try very hard to include this fix.
I have changed my script to use urlencode for all parameters, that is probably the most compatible way.
I would argue that the parsing would be better if it applied some rule to not match a colon after a ? but looking at the spec it is not required