Redirect issue #174

Closed
opened 2020-06-14 18:25:58 +00:00 by makeworld · 9 comments

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.

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.
sloum added the
non-urgent
help wanted
gemini
labels 2020-06-15 06:24:18 +00:00
Owner

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... 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 :(
Author

Hmm, okay thanks. But yeah, relative redirects are allowed. I wonder why this hasn't come up until now.

Hmm, okay thanks. But yeah, relative redirects are allowed. I wonder why this hasn't come up until now.
Owner

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.

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.
Owner

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.

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.
Owner

@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:

  • gemini://aplace.net/stuff/index.gmi
  • gemini://somesite.com/staging/aplace.net/stuff/index.gmi

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.

@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: - gemini://aplace.net/stuff/index.gmi - gemini://somesite.com/staging/aplace.net/stuff/index.gmi 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.
sloum added
in progress
and removed
help wanted
labels 2020-07-02 21:56:51 +00:00
Author

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.

Great, thanks!

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:

  • gemini://aplace.net/stuff/index.gmi
  • gemini://somesite.com/staging/aplace.net/stuff/index.gmi

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 the example.com part is a host, and there is no scheme. Versus just example.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 write example.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/, the Host will be empty, and the Path or RawPath will equal example.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.

> 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. Great, thanks! > 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: > > - gemini://aplace.net/stuff/index.gmi > - gemini://somesite.com/staging/aplace.net/stuff/index.gmi 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 the `example.com` part is a host, and there is no scheme. Versus just `example.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 write `example.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/`, the `Host` will be empty, and the `Path` or `RawPath` will equal `example.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.
Owner

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 that example.com would be fine based on that wording.

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 that `example.com` would be fine based on that wording.
Owner

I believe this has been fixed in the develop release version. I will verify and then close.

I believe this has been fixed in the `develop` release version. I will verify and then close.
sloum closed this issue 2020-09-09 02:28:25 +00:00
Owner

Confirmed. This has been fixed and all test cases are working as expected. Closing now, thanks for your patience :-D

Confirmed. This has been fixed and all test cases are working as expected. Closing now, thanks for your patience :-D
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sloum/bombadillo#174
No description provided.