💾 Archived View for rawtext.club › ~sloum › geminilist › 002065.gmi captured on 2020-09-24 at 01:27:32. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
traderbeckola at tahoma.com traderbeckola at tahoma.com
Sun Jul 5 15:11:18 BST 2020
- - - - - - - - - - - - - - - - - - -
Thanks. In short, I agree. The idea of commenting out that code was to help me get a better handle on where the problem was originating in the broadest sense (client program, server issue, user error). Taking that block out doesn’t help actually fix the problem; it just helped me identify it better as a total gemini (and go lang, and ...) rookie.
Will keep digging to get a better idea of a real solution.
Regards,
ErikOn Jul 5, 2020, 09:15 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
On Sun, Jul 05, 2020 at 08:15:57AM -0400, traderbeckola at tahoma.com wrote:
I played with commenting out the code block in molly-brown that’s relevant to the proxy test; that change will allow the client to connect.
No doubt, but that does nothing to fix the fact that something is
clearly wrong wrong somewhere.
Gemini requests are URLs, with hostnames in them. It's possible in
principle to connect to the foo.com host and send it a request for
gemini://bar.net, and its possible in principle for foo.com to respond
to this by sending the request on to bar.net and then relaying the
response to the original client. This is what is meant by "proxying" in
Gemini.
It is rarely used, and with good reason, as Gemini servers used as
proxies are also "men in the middle". There are legitimate uses,
though: my Agena software will accept Gemini requests for gopher://
URLs, fetch them and the translate Gopher menus into gemtext. I run it
on localhost so it's just "me spying on me". It lets me use AV-98
(which can be configured to forward gopher:// requests to such a proxy)
as both a Gemini client and Gopher client seamlessly, without having to
actually put any Gopher code into AV-98. Any other client could easily
add support for this too.
Anyway, Molly Brown offers no support for any of this. If it receives a
request for a URL with a hostname that doesn't match its configured
hostname, it will respond with a "no proxying allowed" error, and that's
the end of that. The actual server system's hostname is not consulted.
If you're seeing these errors, it can only mean that your client is
sending a URL with the wrong hostname (or there's a bug in Molly Brown,
in which case we should try to identify and fix it, not just comment it
out).
Are you perhaps connecting to the server by typing its IP address into
your client, and not the hostname? That's something I can think of
which would cause this (and perhaps shouldn't).
If that's not the case, look in your Molly Brown access log. You'll be
able to see the URL your client is sending. That will probably let us
know what's going on.
Cheers,
Solderpunk
On Jul 4, 2020, 19:02 -0400, traderbeckola at tahoma.com, wrote:
Yes. Just checked to make sure the hostname is harmonized across molly.conf, hostname on the server system, and the hostname the dns/dhcp server assigns it.
On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
I’m experimenting with setting up a Gemini server (molly brown in this case) on my LAN. It is on a different network segment than my desktop (client, trying out Kristall and elpher). When I try to connect to the server, I get a message “you tried to request a resource from one host that is actually located on another host.... No proxying to other hosts or ports.” The message is similar from the various clients and in the server’s log file.
Not sure why I’m getting this. Running on port 1965, no port forwarding arrangement. There is a firewall between the two network segments.
Thanks!
What's the value of `Hostname` in your Molly Brown configuration, and is
that the hostname with which you are trying to access the server?
Cheers,
Solderpunk-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200705/55b9dad0/attachment-0001.htm>