💾 Archived View for lists.flounder.online › gemini › threads › d4ba82ec3d7f012198ed5a512d9e37a3@post… captured on 2022-04-28 at 19:20:20. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
From: solderpunk@posteo.net
Date: Sun, 07 Nov 2021 15:50:09 +0000
Message-Id: d4ba82ec3d7f012198ed5a512d9e37a3@posteo.net
To: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
--------------------------------------
Greetings Geminauts,
I've just pushed the first changes to the official Gemini specification in close to one year! As always the official specification can be viewed at:
You can also `git clone git://gemini.circumlunar.space/gemini-site` to see individual diffs for spec changes.
A quick preamble: in the gitlab.com repos set up by Sean to work on finalising the specification, the single document form of the current official spec has been replaced by two separate documents, one for the transport protocol and one for the markup language. I think this is a good idea and I intend to adopt it for the official spec. But I also want to work carefully through the proposed changes which made it into that repo and approve or reject them individually. To facilitate this workflow it's easier for me, for now, to "backport" changes to the old format. Once I've decided I'm happy with things I'll backport as much of the new writing as proves to be applicable when translating the format. This is all a bit ugly, but it's not the end of the world. There's real value in having the diffs that actually change spec behaviour as opposed to wording/presentation be short and sweet.
Okay, I have made three changes:
1. Gemini URIs with empty paths (e.g. `gemini://example.com`) and those with paths of `/` (e.g. `gemini://example.com/`) are now equivalent by definition, and both clients and servers SHOULD normalise empty paths to `/` before sending/processing requests (along with applying other standard URI normalisations).
2. The use of the TLS `close_notify` mechanism is now mandatory (see sections 1.1 and 4).
3. The spec is now more explicit about clients not sending anything after a request and servers ignoring anything else they receive after a request.
You can find a little further explanation of my reasoning behind these changes in the corresponding Gitlab issues (#11, #2 and #40).
There are no major changes here. `close_notify` was in fact *already* mandatory via the TLS specs, so we are just being very explicit by repeating that in the Gemini spec. The tightened language in change three is just an attempt to close loopholes. Nobody should have been doing any of the things it prohibits anyway. If you were, you should feel bad. The biggest change is the first one. Depending on how you read RFC 3986, prior to this change it was maybe sorta technically okay for a server to serve different content from gemini://example.com and gemini://example.com/. This is no longer allowed. If you have actually been doing this you need to stop it, you strange, strange person. Both client and server authors should also update their code to normalise URIs (see section 6.2.3 of RFC 3986). Hopefully many will be able to rely on libraries to do this. If you're forced to implement this by hand, the most important normalisation in practice is also one of the simplest: replace an empty path by a `/`. This will help cut down on superfluous redirects.
Even if `close_notify` was not strictly required by the TLS RFCs, it would be logically necessary in Gemini, thanks to the lack of content length information, to disambiguate complete responses from erroneously or malisciously truncated responses. There *are* servers out there which do not reliably use `close_notify`. In principle clients visiting capsules at those servers should interpret this as something having gone wrong and e.g. notify the user or perhaps automatically retry the request. In practice client authors may wish to "be gentle" for a little longer and give server authors time to catch on to this issue before making it difficult/ugly to visit their capsules. Those who provide "torture test" services for server authors should certainly flag lack of `close_notify` as a problem.
Cheers,
Solderpunk
From: solderpunk@posteo.net
Date: Sun, 07 Nov 2021 15:58:24 +0000
Message-Id: 35b02266563039994d1913ad70f2fb6f@posteo.net
To: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
In-Reply-To: d4ba82ec3d7f012198ed5a512d9e37a3@posteo.net
--------------------------------------
Oh dear, some kind of git hook failure means the updates aren't actually visible at the advertised locations. I'm aware and working on it. Sorry!
Cheers,
Solderpunk
From: linde.philip@gmail.com
Date: Sun, 7 Nov 2021 17:09:52 +0100
Message-Id: 20211107170952.abb792074d88f066e94dc706@gmail.com
To: "Solderpunk" <solderpunk@posteo.net>
In-Reply-To: d4ba82ec3d7f012198ed5a512d9e37a3@posteo.net
Cc: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
--------------------------------------
On Sun, 07 Nov 2021 15:50:09 +0000
Solderpunk <solderpunk@posteo.net> wrote:
1. Gemini URIs with empty paths (e.g. `gemini://example.com`) and those
with paths of `/` (e.g. `gemini://example.com/`) are now equivalent by
definition, and both clients and servers SHOULD normalise empty paths to
`/` before sending/processing requests (along with applying other
standard URI normalisations).
Excellent.
Overall a good set of small changes, basically all clarifications that
most implementations should already do right. This makes me hopeful
future changes to the spec will be of the same nature.
--
Philip
From: solderpunk@posteo.net
Date: Sun, 07 Nov 2021 16:12:01 +0000
Message-Id: f94b286b76d0813e695e751eecf4f50a@posteo.net
To: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
In-Reply-To: 35b02266563039994d1913ad70f2fb6f@posteo.net
--------------------------------------
Argh, my bad, the updates *were* visible I just forgot to commit the version number bump. Fixed now. Everything is under control, situation normal...
Cheers,
Solderpunk
On 07.11.2021 16:58, Solderpunk wrote:
Oh dear, some kind of git hook failure means the updates aren't
actually visible at the advertised locations. I'm aware and working
on it. Sorry!
> Cheers,
Solderpunk
From: stephane@sources.org
Date: Sun, 7 Nov 2021 17:16:51 +0100
Message-Id: YYf78zEmpF9yjloY@sources.org
To: "Solderpunk" <solderpunk@posteo.net>
In-Reply-To: d4ba82ec3d7f012198ed5a512d9e37a3@posteo.net
Cc: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
--------------------------------------
On Sun, Nov 07, 2021 at 03:50:09PM +0000,
Solderpunk <solderpunk@posteo.net> wrote
a message of 75 lines which said:
2. The use of the TLS `close_notify` mechanism is now mandatory (see
sections 1.1 and 4).
This will be hard to enforce:
gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
48.3 % of URLs do NOT send a proper TLS shutdown (application
close). Even 36.1 % of those who return status 20 are in that case.
From: solderpunk@posteo.net
Date: Sun, 07 Nov 2021 16:18:14 +0000
Message-Id: 7ab455d92fa59ccb9bbd8e533dd84fdc@posteo.net
To: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
In-Reply-To: 20211107170952.abb792074d88f066e94dc706@gmail.com
--------------------------------------
On 07.11.2021 17:09, Philip Linde wrote:
Excellent.
> Overall a good set of small changes, basically all clarifications that
most implementations should already do right. This makes me hopeful
future changes to the spec will be of the same nature.
My hope is that I can push small, simple batches of clarifications like this once every week or two for the rest of the year and settle most of the outstanding issues. Ideally most of the changes will be such that most implementers need to either do nothing at all or make fairly minor and uncontroversial changes. I don't want to *promise* there will be nothing bigger than this - but I'm reluctant to do things bigger than this and won't do it unless I really think I have to.
Cheers,
Solderpunk
From: solderpunk@posteo.net
Date: Sun, 07 Nov 2021 16:21:53 +0000
Message-Id: 632858d5e3361ced4fcee8dc8bf11c3a@posteo.net
To: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
In-Reply-To: YYf78zEmpF9yjloY@sources.org
--------------------------------------
This will be hard to enforce:
> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
> 48.3 % of URLs do NOT send a proper TLS shutdown (application
close). Even 36.1 % of those who return status 20 are in that case.
Well, then there are (and always has been) a lot of non-compliant servers out there. It's not in my power to put something in the Gemini specification which contradicts what the TLS specifications say.
My hope is that a very large percentage of those URLs come from a relatively small number of server implementations and with a concerted effort we can improve things quickly.
Cheers,
Solderpunk
From: jmcbray@carcosa.net
Date: Mon, 08 Nov 2021 09:28:41 -0500
Message-Id: 87bl2uwwha.fsf@cassilda.carcosa.net
To: "Stephane Bortzmeyer" <stephane@sources.org>
In-Reply-To: YYf78zEmpF9yjloY@sources.org
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Stephane Bortzmeyer <stephane@sources.org> writes:
48.3 % of URLs do NOT send a proper TLS shutdown (application
close). Even 36.1 % of those who return status 20 are in that case.
Please let me know if carcosa.net is among those. Could you also post
a simple program or script for testing this? I feel like we *ought* to
be able to get server authors to fix this pretty easily, unless there
are issues with language bindings making it difficult.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
From: op@omarpolo.com
Date: Mon, 08 Nov 2021 15:40:00 +0100
Message-Id: 87mtme4sjg.fsf@omarpolo.com
To: "Jason McBrayer" <jmcbray@carcosa.net>
In-Reply-To: 87bl2uwwha.fsf@cassilda.carcosa.net
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Jason McBrayer <jmcbray@carcosa.net> writes:
Stephane Bortzmeyer <stephane@sources.org> writes:
> 48.3 % of URLs do NOT send a proper TLS shutdown (application
> close). Even 36.1 % of those who return status 20 are in that case.
Please let me know if carcosa.net is among those. Could you also post
a simple program or script for testing this? I feel like we *ought* to
be able to get server authors to fix this pretty easily, unless there
are issues with language bindings making it difficult.
I always forgot the openssl(1) incantation to check for the close_notify
flag, but portal.mozz.us has a nice UI and clicking on '[view cert]' it
logs the close_notify alert status.
For carcosa.net seems to be absent :/
https://portal.mozz.us/gemini/carcosa.net?crt=1
From: stephane@sources.org
Date: Mon, 8 Nov 2021 16:18:11 +0100
Message-Id: YYk/s3DGBgQceAYj@sources.org
To: "Jason McBrayer" <jmcbray@carcosa.net>
In-Reply-To: 87bl2uwwha.fsf@cassilda.carcosa.net
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
On Mon, Nov 08, 2021 at 09:28:41AM -0500,
Jason McBrayer <jmcbray@carcosa.net> wrote
a message of 15 lines which said:
Please let me know if carcosa.net is among those.
Indeed it is :-(
% agunua carcosa.net
Warning, no TLS shutdown received from the server
__| | ( _` | _|_| _ \(_-< _` | \ -_) _| \___|\__,_|_|\__|\___/___/\__,_|_)_| _|\___|\__|
============================================================
This is the Gemini site for carcosa.net. It is running on Germinal, a Gemini server in Common Lisp.
...
Could you also post a simple program or script for testing this?
gemini://gemini.bortzmeyer.org/software/agunua/
("pip3 install agunua" will work if you have Python installed)
From: linde.philip@gmail.com
Date: Mon, 8 Nov 2021 17:14:18 +0100
Message-Id: 20211108171418.591023cd1d8462a87825c728@gmail.com
To: "Stephane Bortzmeyer" <stephane@sources.org>
In-Reply-To: YYk/s3DGBgQceAYj@sources.org
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Hi Stephane!
On Mon, 8 Nov 2021 16:18:11 +0100
Stephane Bortzmeyer <stephane@sources.org> wrote:
On Mon, Nov 08, 2021 at 09:28:41AM -0500,
Jason McBrayer <jmcbray@carcosa.net> wrote
a message of 15 lines which said:
> Please let me know if carcosa.net is among those.
Indeed it is :-(
% agunua carcosa.net
Warning, no TLS shutdown received from the server
Very useful. I have not considered TLS in detail myself, but I tested
this just now with the Go TLS implementation which does seem to send
the proper notification as you call Close on connections. Good news for
people writing server implementations in Go, I think.
I wonder how hard it would be to automatically identify server software
that doesn't implement this properly. Probably some server software
could be differentiated based on their error code descriptions or how
they deal with some corner cases. If we could trace these capsules to a
few server implementations it might not be too much work to reach out
to the authors and poke at them about the spec change.
With the numbers you suggested earlier, I am wary of strictly enforcing
close_notify in my client, but in the interim maybe client authors
could warn as yours does, or provide some way to add domains to an
exception list.
--
Philip
From: chris@the-brannons.com
Date: Mon, 08 Nov 2021 08:39:27 -0800
Message-Id: 878rxyppog.fsf@the-brannons.com
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: YYk/s3DGBgQceAYj@sources.org
--------------------------------------
Stephane Bortzmeyer <stephane@sources.org> writes:
> Could you also post a simple program or script for testing this?
gemini://gemini.bortzmeyer.org/software/agunua/
("pip3 install agunua" will work if you have Python installed)
The gemini-diagnostics tool
<https://github.com/michael-lazar/gemini-diagnostics> also does the
no-shutdown check.
-- Chris
From: op@omarpolo.com
Date: Mon, 08 Nov 2021 17:43:55 +0100
Message-Id: 87sfw61tif.fsf@omarpolo.com
To: "Chris Brannon" <chris@the-brannons.com>
In-Reply-To: 878rxyppog.fsf@the-brannons.com
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Chris Brannon <chris@the-brannons.com> writes:
Stephane Bortzmeyer <stephane@sources.org> writes:
>> Could you also post a simple program or script for testing this?
>
> gemini://gemini.bortzmeyer.org/software/agunua/
>
> ("pip3 install agunua" will work if you have Python installed)
The gemini-diagnostics tool
<https://github.com/michael-lazar/gemini-diagnostics> also does the
no-shutdown check.
I'm not sure that it works correctly. I tried against gmid (my server)
and it always fails the close_notify test, even though both
portal.mozz.us and agunua agree that the close_notify alert is sent.
It's a useful tool otherwise.
-- Chris
From: stephane@sources.org
Date: Mon, 8 Nov 2021 18:03:35 +0100
Message-Id: YYlYZ+PkXpt9M9O5@sources.org
To: "Philip Linde" <linde.philip@gmail.com>
In-Reply-To: 20211108171418.591023cd1d8462a87825c728@gmail.com
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
On Mon, Nov 08, 2021 at 05:14:18PM +0100,
Philip Linde <linde.philip@gmail.com> wrote
a message of 35 lines which said:
I wonder how hard it would be to automatically identify server
software that doesn't implement this properly. Probably some server
software could be differentiated based on their error code
descriptions or how they deal with some corner cases.
Yes, fingerprinting servers is certainly possible. Someone to take
this project?
Note that some servers send the TLS proper close for "normal" replies
but fail to do so when there is an error, such as 51. It helps with
fingerprinting, though.
From: alex@alexschroeder.ch
Date: Mon, 8 Nov 2021 18:07:41 +0100
Message-Id: 59F9D7F6-9382-461B-8FB4-40F926DA1C8D@alexschroeder.ch
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: 87bl2uwwha.fsf@cassilda.carcosa.net
--------------------------------------
Regarding the closing of connections:
I know from using gemini-diagnostics that my server is one of those. I just use a generic Perl async server framework and call “close_gracefully” at the end but somewhere in the layers of libraries from Mojo::IOLoop to IO::Socket::SSL to Net::SSLeay to OpenSSL somebody doesn’t handle this the way people expect it to work and I have no idea how to fix it (and I have stared at the source code of all these libraries for more hours than I cared for). So if anybody knows how to fix this using Perl, I’m interested in hearing about it. I got some helpful hints on Station so perhaps yet another look into it all will finally enlighten me.
--
Typed on a tiny keyboard. Sorry for being terse.
On 8 Nov 2021, at 15:31, Jason McBrayer <jmcbray@carcosa.net> wrote:
Stephane Bortzmeyer <stephane@sources.org> writes:
> 48.3 % of URLs do NOT send a proper TLS shutdown (application
> close). Even 36.1 % of those who return status 20 are in that case.
Please let me know if carcosa.net is among those. Could you also post
a simple program or script for testing this? I feel like we *ought* to
be able to get server authors to fix this pretty easily, unless there
are issues with language bindings making it difficult.
From: jmcbray@carcosa.net
Date: Mon, 08 Nov 2021 19:43:36 -0500
Message-Id: 87zgqetaxu.fsf@cassilda.carcosa.net
To: "Omar Polo" <op@omarpolo.com>
In-Reply-To: 87mtme4sjg.fsf@omarpolo.com
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Omar Polo <op@omarpolo.com> writes:
For carcosa.net seems to be absent :/
https://portal.mozz.us/gemini/carcosa.net?crt=1
Ugh, thanks. I will have to look into it, and just hope the wrapper I'm
using doesn't make it too difficult.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
From: jmcbray@carcosa.net
Date: Mon, 08 Nov 2021 19:44:54 -0500
Message-Id: 87v912taus.fsf@cassilda.carcosa.net
To: "Stephane Bortzmeyer" <stephane@sources.org>
In-Reply-To: YYk/s3DGBgQceAYj@sources.org
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Stephane Bortzmeyer <stephane@sources.org> writes:
On Mon, Nov 08, 2021 at 09:28:41AM -0500,
Jason McBrayer <jmcbray@carcosa.net> wrote
a message of 15 lines which said:
> Please let me know if carcosa.net is among those.
Indeed it is :-(
Thanks. Clearly, using cl+ssl in the default ways doesn't close the
connection properly; hopefully it won't be too difficult to make it
happen.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
From: neruvi[at]disroot[dot]org@
Date: Tue, 9 Nov 2021 08:28:35 +0000
Message-Id: 20211109082835.GB4051@host
To: "Stephane Bortzmeyer" <stephane@sources.org>
In-Reply-To: YYlYZ+PkXpt9M9O5@sources.org
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
On Mon, 2021-11-08, Stephane Bortzmeyer wrote:
Note that some servers send the TLS proper close for "normal" replies
but fail to do so when there is an error, such as 51.
Molly Brown among them, according to Agunua:
$ agunua gemini://rawtext.club/no-such-page
Warning, no TLS shutdown received from the server
Problem, Not found (extra message: "Not found!").
From: stephane@sources.org
Date: Wed, 10 Nov 2021 08:30:27 +0100
Message-Id: YYt1E0je4r3AAr/P@sources.org
To: "nervuri" <neruvi[at]disroot[dot]org@>
In-Reply-To: 20211109082835.GB4051@host
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
On Tue, Nov 09, 2021 at 08:28:35AM +0000,
nervuri <neruvi[at]disroot[dot]org@> wrote
a message of 9 lines which said:
> Note that some servers send the TLS proper close for "normal" replies
> but fail to do so when there is an error, such as 51.
Molly Brown among them, according to Agunua:
Indeed, see for instance the official site :-(
% agunua gemini.circumlunar.space
...
% agunua gemini.circumlunar.space/doesnotexist
Warning, no TLS shutdown received from the server
Problem, Not found (extra message: "Not found!").
From: jmcbray@carcosa.net
Date: Thu, 11 Nov 2021 14:29:16 -0500
Message-Id: 87bl2qzdu6.fsf@cassilda.carcosa.net
To: "Jason McBrayer" <jmcbray@carcosa.net>
In-Reply-To: 87v912taus.fsf@cassilda.carcosa.net
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Jason McBrayer <jmcbray@carcosa.net> writes:
Thanks. Clearly, using cl+ssl in the default ways doesn't close the
connection properly; hopefully it won't be too difficult to make it
happen.
I'm pleased to note that this was an upstream bug, in CL+SSL, which has
been fixed. Anyone who installed Germinal the default way (Roswell and
quicklisp) should run (ql:update-all-dists) and (ql:quickload :cl+ssl)
to upgrade their CL+SSL and restart Germinal.
I added a line of code to explicitly close TLS streams, but I don't
believe it was actually needed; CL+SSL should be doing the right thing
when streams are implicitly closed.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
From: krixano@protonmail.com
Date: Mon, 15 Nov 2021 01:38:48 +0000
Message-Id: 2nwrXDTZoz9y3utUr7BVSzjefhaCbv2VEqCxVH97UnIWkV8mh87Bntdmiuk533ez7hNLqozOmUoDjE73Xv5pws-3i8wzZpPDP8wdHU91c3o=@protonmail.com
To: "A protocol that is slightly more complex than gopher,but significantly simpler than HTTP" <gemini@lists.orbitalfox.eu>
In-Reply-To: kTBFLMEvG6nkZW6IZk5xwx5FtQLNJF32lt14b7HIPHe6VrSACfh_j3NLE4siJ9iY3WbPa6bAjwG6_pP1cHxtRTpUpKV1acavYLjIxRpyutg=@protonmail.com
--------------------------------------
Forwarding the message I sent below to the rest of the mailing list as I accidentally hit "Reply" instead of "Reply All".
Christian Seibold
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, November 14th, 2021 at 7:37 PM, Krixano <krixano@protonmail.com> wrote:
I wanted to write here to confirm that anything using the Gig Framework (https://github.com/pitr/gig) should be doing close_notify correctly, as I checked my capsule with portal.mozz.us for this case. I'll also notify the developer as well.
Christian Seibold
Sent with ProtonMail Secure Email.
From: krixano@protonmail.com
Date: Mon, 15 Nov 2021 02:44:14 +0000
Message-Id: YUa8g2vbJ1GcQTTomf6Ts0XrG784rbRuWv_RdsVYeY1bFBBVKO0Mky1YYfKnSwGYN7DNUzygVLJmJk3z9DQaCMhXmbJ1IWaDqDb9BodKHsM=@protonmail.com
To: "Krixano" <krixano@protonmail.com>
In-Reply-To: 2nwrXDTZoz9y3utUr7BVSzjefhaCbv2VEqCxVH97UnIWkV8mh87Bntdmiuk533ez7hNLqozOmUoDjE73Xv5pws-3i8wzZpPDP8wdHU91c3o=@protonmail.com
Cc: "A protocol that is slightly more complex than gopher,but significantly simpler than HTTP" <gemini@lists.orbitalfox.eu>
--------------------------------------
Correction, I looked into it further. The Gig Framework does the close_notify correctly on most pages, but does not do it for pages that give error codes (I haven't checked all error codes yet, but I have checked the not found error code).
Christian Seibold
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, November 14th, 2021 at 7:37 PM, Krixano krixano@protonmail.com wrote:
> I wanted to write here to confirm that anything using the Gig Framework (https://github.com/pitr/gig) should be doing close_notify correctly, as I checked my capsule with portal.mozz.us for this case. I'll also notify the developer as well.
>
> Christian Seibold
>
> Sent with ProtonMail Secure Email.
From: krixano@protonmail.com
Date: Mon, 15 Nov 2021 03:28:44 +0000
Message-Id: iUIBX-IDsNwj8k8lYn7P0Jh7pU36Ufii_q-90B1KiY192tShtFD06DDWPwF8tMTwS2ShrOS3TXZIplzJD5m8GSTd0nYDrK_BV5RM0-S5axA=@protonmail.com
To: "Krixano" <krixano@protonmail.com>
In-Reply-To: YUa8g2vbJ1GcQTTomf6Ts0XrG784rbRuWv_RdsVYeY1bFBBVKO0Mky1YYfKnSwGYN7DNUzygVLJmJk3z9DQaCMhXmbJ1IWaDqDb9BodKHsM=@protonmail.com
Cc: "A protocol that is slightly more complex than gopher,but significantly simpler than HTTP" <gemini@lists.orbitalfox.eu>
--------------------------------------
So, I've tested some capsules with agunua. This is the list of capsules that have had close_notify on pages that were found, but did not have it on pages that were not found. This list is also every single url that I've tested so far where the issue has come up - all of the tests have just been for the Not Found errorcode. I have also included the server software (if known):
gemini://gemini.bortzmeyer.org/blashsdfh - gemserv
gemini://skyjake.fi/blahkslhdf
gemini://astrobotany.mozz.us/blahssldhslh
gemini://botond.online/blashlhsdfh
station.martinrue.com/blahsdlhsdlfh
gemini://kwiecien.us/blajjjsdhsdh - geminid
gemini://auragem.space/notfound - Gig Framework
gemini.circumlunar.space/blahdhd - Molly Brown
gemini://geminispace.info/blashldshfsldhf
gemini://marginalia.nu/blahdslkhdfh - custom server
gemini://gemini.thegonz.net/aslhsdlhfsdfh
gemini://geminiquickst.art/blashdslfhsldhf
gemini://nytpu.com/blahsdlhfsfdlh
gemini://konpeito.media/blashsldhsdlfh
gemini://rawtext.club/blashsldh
gemini://srht.site/blashlsdhf
gemini://godocs.io/blashdlfkh
I just want to make sure about this, are we sure agunua is reporting things correctly? I find it odd that *every single server* I've tested has had this problem with the notfound errorcode, but not with successful requests.
Christian Seibold
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, November 14th, 2021 at 8:44 PM, Krixano <krixano@protonmail.com> wrote:
Correction, I looked into it further. The Gig Framework does the close_notify correctly on most pages, but does not do it for pages that give error codes (I haven't checked all error codes yet, but I have checked the not found error code).
Christian Seibold
Sent with ProtonMail Secure Email.
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Sunday, November 14th, 2021 at 7:37 PM, Krixano krixano@protonmail.com wrote:
>
> > I wanted to write here to confirm that anything using the Gig Framework (https://github.com/pitr/gig) should be doing close_notify correctly, as I checked my capsule with portal.mozz.us for this case. I'll also notify the developer as well.
> >
> > Christian Seibold
> >
> > Sent with ProtonMail Secure Email.
From: balazsbotond@gmail.com
Date: Mon, 15 Nov 2021 12:33:13 +0100
Message-Id: CAOEKZX9Op9VmsjfUG+iWw=gOoSeKarVEmn2ce1yODOB3-BXFpQ@mail.gmail.com
To: "Krixano" <krixano@protonmail.com>
In-Reply-To: iUIBX-IDsNwj8k8lYn7P0Jh7pU36Ufii_q-90B1KiY192tShtFD06DDWPwF8tMTwS2ShrOS3TXZIplzJD5m8GSTd0nYDrK_BV5RM0-S5axA=@protonmail.com
Cc: "A protocol that is slightly more complex than gopher,but significantly simpler than HTTP" <gemini@lists.orbitalfox.eu>
--------------------------------------
On Mon, Nov 15, 2021 at 4:29 AM Krixano <krixano@protonmail.com> wrote:
I just want to make sure about this, are we sure agunua is reporting things correctly? I find it odd that *every single server* I've tested has had this problem with the notfound errorcode, but not with successful requests.
I filed a bug for the server I use (Agate) and from the maintainer's
comment it seems that there is indeed a problem with Agunua:
https://github.com/mbrubeck/agate/issues/100#issuecomment-965174851
From: jmcbray@carcosa.net
Date: Mon, 15 Nov 2021 08:15:55 -0500
Message-Id: 87k0h91qze.fsf@cassilda.carcosa.net
To: "Krixano" <krixano@protonmail.com>
In-Reply-To: iUIBX-IDsNwj8k8lYn7P0Jh7pU36Ufii_q-90B1KiY192tShtFD06DDWPwF8tMTwS2ShrOS3TXZIplzJD5m8GSTd0nYDrK_BV5RM0-S5axA=@protonmail.com
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Krixano <krixano@protonmail.com> writes:
I just want to make sure about this, are we sure agunua is reporting
things correctly? I find it odd that *every single server* I've tested
has had this problem with the notfound errorcode, but not with
successful requests.
I believe agunua has a problem with reporting no close_notify on error
pages, reporting that it is absent whether it was actually sent or
not. I spent some time over the weekend fixing this issue in Germinal,
making sure that the same code-paths were used for both 2x responses and
for errors, but agunua still reported no close_notify for 51 pages. I
checked the same error pages with portal.mozz.us, and it *is* seeing the
close_notify being sent. So, I'm going to assume the error is in agunua.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
From: alex@nytpu.com
Date: Mon, 15 Nov 2021 08:29:19 -0700
Message-Id: 20211115152919.vwkchs725kqckh3y@GLaDOS.local
To: "Gemini Mailing List" <gemini@lists.orbitalfox.eu>
In-Reply-To: iUIBX-IDsNwj8k8lYn7P0Jh7pU36Ufii_q-90B1KiY192tShtFD06DDWPwF8tMTwS2ShrOS3TXZIplzJD5m8GSTd0nYDrK_BV5RM0-S5axA=@protonmail.com
--------------------------------------
Luckily it's pretty easy to test this with openssl's s_client, it'll say
"closed" at the end if the connection was closed properly:
printf "gemini://nytpu.com/about.gmi\r\n" |
openssl s_client -ign_eof -connect nytpu.com:1965
outputs:
depth=0 O = nytpu, CN = nytpu.com
verify error:num=18:self signed certificate
[...handshake and cert info...]
20 text/gemini; lang=en-US
[...the actual response body (if success response code)...]
[...end-of-connection info...]
closed
Here's a handy little shell function where you give it a URI and it'll
check if it's closed properly or not:
test_close_notify() {
hostname="$(printf "$1" | sed -e 's/[^/]*\/\/\([^@]*@\)\?\([^:/]*\).*/\2/')"
output="$(printf "%s\r\n" "$1" |
openssl s_client -ign_eof -connect "${hostname}:1965" 2>&1 |
tail -n1 | tr -d '\n')"
if [ "${output}" = "closed" ]; then
printf "close_notify for '%s' properly recieved.\n" "$1" >&2
else
printf "close_notify for '%s' not received!\n" "$1" >&2
fi
}
~nytpu
--
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com