No proxying to other hosts when visiting gemini://gemini.circumlunar.space #97
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#97
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?
Error message when visiting gemini://gemini.circumlunar.space:
[5] Permanent Failure. No proxying to other hosts!
(just noticed it when checking links on the gopher user guide, haven't done much investigation as I have to go soon, no idea if it's something with Bombadillo or with the other server)
That is a weird one. That server has been having some issues. I have been in touch with solderpunk to deal with an unrelated issue (re: logging in via sftp to that server) and have brought up this issue as well. It does appear to be an issue with the server (the error message comes from them, not from Bombadillo), but I'll let you know if solderpunk is able to shed any light on the situation.
I checked this about 15 hours ago and it was working then, and is still working now.
Perhaps clarifying the intended meaning of the error message would be useful, but I don't have a direct suggestion as to how this could be done. This is something that you see on the web now, having evolved over many years of effort, and it's still confusing enough that documents like this exist as a supplement.
What are your thoughts?
I heard from solderpunk and they looked into the issue. Their server uses the Go
net/url
package. That package does not separate out the port from the host. They were trying to do a comparison to validate the request and did not expect a port to be provided and then included in the host field. solderpunk updated the code to check for a port and split it out. So we should be good to go with that gemini site now.Since gemini is designed to have the server provide the error messaging specifics (rather than the client, which just passes on the error code, error code meaning, and the message from the server) I do not think there is much to be reliably added by Bombadillo the error beyond the message prefix (
[5] Permanent Failure
), which is set, more or less, by the gemini spec. This design does open the door for less clear messaging sometimes. The message we received is accurate for what was happening, it was just unclear without emailing the admin why it was happening.Thanks for looking in to this situation and letting me know what went on. Glad it is fixed now.
I take your point on this, and reviewed the status codes in the spec again to try to understand this better. It does have a specific suggestion for displaying status codes 4 and 5, but it seems like it would not be useful here either.
The important part for me is the determination from the message that this is a server error and not an issue with Bombadillo. It seems like it's not possible to communicate that?
Hmm... probably not. In this case it was a server error... but it, in theory, would have been possible for a client to send a request that would get that response. Bombadillo couldnt (it isnt an option for users), but it is in theory possible for a client to allow cross site resource requests. Either would result in an error code 5 situation.
OK then, let's close this off. Not an issue with Bombadillo, correct process followed by the client for a server issue.