Recently, I attempted to navigate to my capsule gemini://MatthiasPortzel.com, with capital letters. I found that my Gemini server (a custom server implementation) didn’t respond to that URL, since I was preforming a case-sensitive hostname match. I would like to be able to stylize my domain name with capital letters sometimes to make my first and last name easier to distinguish. (MatthiasPortzel is more readable than matthiasportzel.)
I changed my capsule to preform a case-insensitive match, to match what I expect from DNS and HTTP.
However, I then tried requesting different capitalizations of other popular Gemini capsules. And hardly any of them responded to changed capitalizations. I believe Molly Brown, Agate, Jetforce, and others, do this simple case-sensitive hostname check.
So I wanted to ask the mailing list. Is this a bug that exists in a significant number of Gemini server implementations that no one has noticed before? Or is it the responsibility of someone else (like the Gemini client or the author of the link) to ensure that domain names are lowercase? Neither Lagrange or Amfora lowercase domain names. On the HTTP side, I believe that Apache’s virtual hosting is case-insensitive, and additionally, it appears that Chrome and Safari lowercase domain names before sending them.
The intuitive behavior here is definitely that case shouldn’t effect domain names. So I would guess that these servers need to be patched. Unless there are objections, it might be worth adding a line to the specification to that effect.
On Sat, Nov 20, 2021 at 02:36:37AM -0500,
Matthias Portzel <email@example.com> wrote
a message of 85 lines which said:
> I believe Molly Brown, Agate, Jetforce, and others, do this simple
> case-sensitive hostname check.
> The intuitive behavior here is definitely that case shouldn’t effect
> domain names.
It is not just intuition, it is the standard. RFC 1034, on DNS, in
its section 3.1 "By convention, domain names can be stored with
arbitrary case, but domain name comparisons for all present domain
functions are done in a case-insensitive manner, assuming an ASCII
character set, and a high order zero bit." And section 3.5 "Note that
while upper and lower case letters are allowed in domain names, no
significance is attached to the case. That is, two names with the
same spelling but different case are to be treated as if identical."
Also, in RFC 3986 on URI, section 3.2.2 "The host subcomponent is
(IDN complicate things a bit and, unfortunately, Gemini standard is
silent about IDN.)
> So I would guess that these servers need to be patched.
Indeed, there are clearly wrong and deserve a bug report.
> Unless there are objections, it might be worth adding a line to the
> specification to that effect.
Here, I disagree. The standard is already clear. A standard is not
supposed to mention all the ways the readers can be wrong. (A
companion document "Things to keep in mind when implementing the
standard" could be useful but not the specifictaion itself.)
Just posting there here to say that any servers that use Gig Framework should be fine. Also, I'm actually quite surprised so many servers have this problem.
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, November 21st, 2021 at 8:59 AM, Adrian Hesketh <firstname.lastname@example.org> wrote:
> Thanks, good point. I've updated a-h/gemini to fix this, see https://github.com/a-h/gemini/issues/15
On Sat, Nov 20, 2021 at 2:37 AM Matthias Portzel
> However, I then tried requesting different capitalizations of other popular Gemini capsules. And hardly any of them responded to changed capitalizations. I believe Molly Brown, Agate, Jetforce, and others, do this simple case-sensitive hostname check.
I went to fix this in Jetforce because I don't remember ever
implementing a case-insensitive check, but it looks like it already
works! It turns out that if you're using the python standard library
URL parser, it will automatically lowercase the hostname component for
>>> from urllib.parse import urlparse