Redirect issue #174
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#174
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Experienced this on
gemini://fkfd.me/git/cgi/
, when I clicked the mcross link. It redirects to a summary page, but Bombadillo tries to load a host called summary.Hmm... That is weird. I can confirm that that is occuring, and that it does not seem to affect other clients (at least av98 and the two web proxies anyway). I assume that the header line that comes back is
30 summary
as that is bombadillo's behavior: ask if you would like to be redirected to the supplied link. Given that I know redirects work in pretty much all other situations I have encountered I have to guess that something weird is happening with the host here. Not sure what though. Maybe they are trying to pass a relative link via a redirect? If that is the case, I know Bombadillo does not support that and while I suppose it is probably allowed, it should be against best practices. If I pass the server a full URL it should give me a full URL back as a redirect (if a redirect is needed at all).This falls into the same camp as other gemini issues currently: outside contributors are welcome to patch and submit a pull, but I am no longer updating the gemini module for bombadillo for the foreeable future. Sorry :(
Hmm, okay thanks. But yeah, relative redirects are allowed. I wonder why this hasn't come up until now.
Hmmm. That must be semi-recent (since the hacker news article) that relative redirects got officially added to the spec. I do not think that should be allowed. Certainly it is a weird behavior and I am surprised servers have implemented it. I udnerstand why authors of "content" would want relative links... but the server has the full resource address and it seems weird and fragile to me for a server to return a relative redirect.
Just updating to let you know that I hope to get this fix into the 2.3.2 release that is currently coming together. I'll update the tags here when I actually start working on this issue and then post a link to the PR once it is up.
@makeworld
PR #182 is currently open with a fix for this issue. I have verified that it solves the specific case mentioned in the issue and seems logically consistent to solve the issue in general.
While researching a bit recently I was looking at the gemini spec and was shocked to find out that it does not require a scheme to be present in a link. This is totally broken, aprticularly for multiprotocol clients. So depending on what happens with that all of the relative link stuff in Bombadillo may need a change.
I sent solderpunk the following example:
I am currently at: gemini://somesite.com/staging/index.gmi
I see the following link line:
=> aplace.net/stuff/index.gmi
Does that produce:
There is no reason that the second one is an invalid url... In bombadillo if I treat the link as a host an not as a relative link it would actually produce a gopher link for me since that is my default scheme.
Ugh. Relative links have been way more complex than they are really worth. :-/
Lol, sorry for the side-chatter. I am hopeful that the above goes a sensible way and makes the work that has been done to make relative links function better in Bombadillo work out well.
Great, thanks!
I think I'll be able to beat Solderpunk to the punch on this one. I thought this was an issue too, but I was informed on IRC that I just need to learn more about how URLs work haha. The example link you provided can only be a relative link.
A scheme-less URL looks like
//example.com/
, with the//
prefix indicating that theexample.com
part is a host, and there is no scheme. Versus justexample.com/
, which is a relative link. It's just confusing because you never see URLs written like that, and Gemini and Web browsers alike are nice to us, and let us writeexample.com
in the URL bar and add the rest.The Golang URL parsing library will follow this rule, I've tested it myself when I was building Amfora. For URLs like
example.com/
, theHost
will be empty, and thePath
orRawPath
will equalexample.com/
.However, you shouldn't need to worry about this. If you just use
pageURL.ResolveReference(linkURL)
, Go's stdlib will handle everything properly.Hope this helps! Let me know if you don't call Solderpunk off, and he responds with something different then what I said.
That is what I thought!! Awesome. That is good news and means what I have been doing is ok. My example had definitely been meant to show that that should be interpreted as a relative link and I am glad to hear that I am correct on that.
I will still let solderpunk respond, but mostly just so as to not fill his inbox with more of my email (we've been emailing a lot), but you definitely answered this sufficiently to have resolved my fears. I do wonder if the spec should get updated to make that a bit more clear when they say that
gemini should be assumed
if a scheme is missing, as most people that have not read a spec of been on the mailing list (ie. most people writing content and not servers/clients) would assume thatexample.com
would be fine based on that wording.I believe this has been fixed in the
develop
release version. I will verify and then close.Confirmed. This has been fixed and all test cases are working as expected. Closing now, thanks for your patience :-D