It seems there is a specific brand of server that immediately resets the connection when you ask a non-existing file (such as robots.txt) instead of replying with 51. You can find it for instance at fulton.software, blog.snowfrost.garden or cee64.us. Any idea what it is?
You can identify gemini servers by their error messages (try getting "59 BAD REQUEST" or "53 PROXY REQUEST REFUSED")
On Mon, Sep 27, 2021 at 02:21:44PM +0500, Anna “CyberTailor” <cyber@sysrq.in> wrote a message of 2 lines which said: > You can identify gemini servers by their error messages (try getting > "59 BAD REQUEST" or "53 PROXY REQUEST REFUSED") I don't see how it would help to find out *which* software has the bug. This one never reply when there is a problem with the request, it just shuts down the connection.
I've noticed station.martinrue.com doesn't seem to implement the spec correctly (to my knowledge). I experimented with using a TLS client (gnutls-cli) to send messages over the protocol manually and Station replied weirdly to requests. It responds to 'gemini://gemini.circumlunar.space/' with '20 text/gemini' and then the home page. Shouldn't that be something like '53 We are not a proxy'? It responds to 'http://njw.name/' with '59 Client scheme is non-gemini'. Shouldn't that also be 53? -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox at https://tutanota.com or https://protonmail.ch. https://fastmail.fm is not encrypted but has some privacy. You can search for more providers. 27 Sept 2021, 12:00 by gemini-request@lists.orbitalfox.eu: > Send Gemini mailing list submissions to > gemini@lists.orbitalfox.eu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.orbitalfox.eu/listinfo/gemini > or, via email, send a message with subject or body 'help' to > gemini-request@lists.orbitalfox.eu > > You can reach the person managing the list at > gemini-owner@lists.orbitalfox.eu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gemini digest..." > > > Today's Topics: > > 1. [Tech] A broken server in the wild, tearing down connection > when the resource does not exist? (Stephane Bortzmeyer) > 2. Re: [Tech] A broken server in the wild, tearing down > connection when the resource does not exist? (Anna ?CyberTailor?) > 3. Gemini Usenet Newsgroup (Jason Evans) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Sep 2021 20:30:31 +0200 > From: Stephane Bortzmeyer <stephane@sources.org> > To: gemini@lists.orbitalfox.eu > Subject: [Tech] A broken server in the wild, tearing down connection > when the resource does not exist? > Message-ID: <YVC8R6z+YmcpD7m6@sources.org> > Content-Type: text/plain; charset=us-ascii > > It seems there is a specific brand of server that immediately resets > the connection when you ask a non-existing file (such as robots.txt) > instead of replying with 51. > > You can find it for instance at fulton.software, blog.snowfrost.garden > or cee64.us. > > Any idea what it is? > > > ------------------------------ > > Message: 2 > Date: Mon, 27 Sep 2021 14:21:44 +0500 > From: Anna ?CyberTailor? <cyber@sysrq.in> > To: gemini@lists.orbitalfox.eu > Subject: Re: [Tech] A broken server in the wild, tearing down > connection when the resource does not exist? > Message-ID: <YVGNKDRQZe+MPq5e@sysrq.in> > Content-Type: text/plain; charset=us-ascii > > You can identify gemini servers by their error messages (try getting > "59 BAD REQUEST" or "53 PROXY REQUEST REFUSED") > > > ------------------------------ > > Message: 3 > Date: Mon, 27 Sep 2021 11:39:03 +0200 > From: Jason Evans <jsevans@mailfence.com> > To: gemini@lists.orbitalfox.eu > Subject: Gemini Usenet Newsgroup > Message-ID: <896aaba2-3d3e-1661-feb3-b095aeb1b4dc@mailfence.com> > Content-Type: text/plain; charset=UTF-8 > > Hi all, > > If anyone is interested, I can start putting together a proposal for a > Gemini Usenet newsgroup. comp.infosystems.gopher is still around and > active. A new comp.infosystems.gemini could be created in the classic > Usenet Big-8 hierarchies but we need people who are willing to say that > they would use it before it could be created. > > Full disclosure: I am a member of the Usenet Big-8 Management Board > which creates and manages the Big-8 Usenet Hierarchies. see: > https://en.wikipedia.org/wiki/Big_8_(Usenet) and https://big-8.org and > we are looking to create groups for people who want to use Usenet. We're > not for profit and we don't make any money except enough to cover expenses. > > Jason > > > > ------------------------------ > > Subject: Digest Footer > > Gemini mailing list > Gemini@lists.orbitalfox.eu > https://lists.orbitalfox.eu/listinfo/gemini > > > ------------------------------ > > End of Gemini Digest, Vol 26, Issue 34 > ************************************** >
On Sun, Sep 26, 2021 at 08:30:31PM +0200, Stephane Bortzmeyer <stephane@sources.org> wrote a message of 8 lines which said: > It seems there is a specific brand of server that immediately resets > the connection when you ask a non-existing file (such as robots.txt) > instead of replying with 51. > > You can find it for instance at fulton.software, blog.snowfrost.garden > or cee64.us. > > Any idea what it is? Eleven capsules has apparently this issue (they probably all run the same software): gemini.real-ity.com gmni.kizaing.ca stillspinning.cc lertsenem.com iich.space capsule.adrianhesketh.com gemini.barca.mi.it tryops.net fulton.software lord.re cee64.us Robert khuxkm Miles suggests: The culprit seems to be the blog software written by Fulton (presumably of fulton.software)[1]. While Fulton's `rfs` server correctly handles non-existant files[2], `blog` lacks the final `header 51 'File not found'` of `rfs`. Thus, when `blog` terminates with no input, the connection is reset with no output. I would presume that this is the same issue plaguing cee64.us, given the similarity of their main page to Fulton's own fulton.software, and the same issue plaguing blog.snowfrost.garden, which seems to be running a modified version of `blog`, if it is running one at all. If blog.snowfrost.garden isn't in fact running `blog`, I would presume the issue to be a similar omission of the final `header 51 'File not found'` in whatever their software is written in. [1]: https://git.sr.ht/~fultonbrowne/g9srv/tree/master/item/blog [2]: https://git.sr.ht/~fultonbrowne/g9srv/tree/master/item/rfs
---
Previous Thread: Lost: post about branding on a personal capsule