💾 Archived View for mozz.us › journal › 2020-06-08.gmi captured on 2023-11-04 at 11:38:24. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Published 2020-06-08
~solderpunk just published a new version of the spec. Overall, I'm either positive or neutral toward all of the new changes. I already went through the implications and updated my jetforce server and portal.mozz.us HTTP proxy. I'm a big fan of the "IMPLICATIONS" section in the announcements, it makes it so much easier to figure out what parts I need to pay attention to.
[SPEC-CHANGE] lang parameter, minor line type changes, clarifications...
https://github.com/michael-lazar/jetforce
You SHOULD consider providing a way for admins and/or users to specify which value of the "lang" parameter should be sent for text/gemini content.
I added a new "--default-lang" flag to jetforce (still on the master branch, not released yet). Specifying a value will append the "lang" parameter to all text/gemini responses. It's crude but it works. I think ideally, content authors would be able to mark specific directories or files as containing different languages. But that sounds like a pain in the ass to configure.
Why only text/gemini and not text/plain? I can already add "charset=" to other text/* responses. Why would I not want to add a "lang=" to a plaintext or a markdown document as well? I don't understand the reasoning there.
My site now serves a default lang of "en".
If your server automatically generates text/gemini content (e.g. directory listings), you MUST make sure it uses percent-encoding in its URLs (filenames with spaces in them are a good test case!).
This was already fixed in jetforce about a week ago, thanks to tomasino for the bug report!
Your client MAY make use of the value of the "lang" parameter in interpreting text/gemini content (this will mostly be relevant for the Rhapsode audio browser and perhaps for search engines).
My HTTP proxy was already parsing the extra meta parameters to get the "charset=", so extracting the lang was no extra work. If a lang is presented by the server, it will be inserted into the gemini content <div> tag:
<div class="body" lang="...">
I doubt this will ever be used for anything, but hey, at least I can say that I'm following the spec. I appreciate that in HTML, I can limit the lang tag to *only* the proxied gemini response and not the entire HTML document. I wouldn't want this level of granularity in the text/gemini spec. But it does feel more "correct" to do it this way.
If your client recognises unordered list item lines and treats them differently from plain text lines, you MUST change the code which identifies them to require a space after the *.
Done, and I'm happy to make this change! While I was looking at bullets, I also went ahead and tweaked my CSS for unordered lists to remove the extra indent. Now they line up with the other text on the page.
You MAY update your client to recognise the new quote line type.
Done. I still have mixed feelings about this one.... I guess we can try it out and see how it goes. I'm using a <blockquote> tag with some minimal styling to distinguish it from other types of text. I'm also removing the first ">" and replacing it with a vertical line. That's allowed, right? Should I be stripping extra whitespace between the arrow and the text? Currently I am not.
No whitespace, no problem.
One whitespace, this should probably be stripped.
Four whitespaces, this was probably on purpose and should be preserved.
You MAY update your client to treat status code 11 differently from status code 10.
I like this addition a lot. In HTML-land, all I had to do was replace the input "type=text" with "type=password".
I wrote a little CGI script to try this out. It's also a minimal example of how one might implement username/password authentication without using a session or a transient client certificate:
(type anything for the username/password)
Here's the code:
#!/usr/local/bin/python3
import os
from urllib.parse import unquote
username = os.environ["PATH_INFO"]
query = os.environ["QUERY_STRING"]
if not username:
if not query:
print("10 Enter your username: ")
else:
print(f"30 login/{query}")
else:
if not query:
print("11 Enter your password: ")
else:
print("20 text/gemini")
print("You have been logged in!")
print("")
print(f"Username: {unquote(username[1:])}")
print(f"Password: {unquote(query)}")
If your client supports status codes beginning with 1, you MUST be percent-encoding the user input when formatting the subsequent request.
I'm glad this is explicitly being called out in the spec, since many of us coming from gopher may expect different behavior.
If your client has been automatically making network connections you MUST remove this behaviour and atone for your sins!
???