[Tech] A broken server in the wild, tearing down connection when the resource does not exist?

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