💾 Archived View for soviet.circumlunar.space › oak › mailinglist › 20.gmi captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Date: Sat, 30 Jan 2021 15:27:25 +0100
Hello,
I've started using gemini around last October, but I never announced my
capsule. In these last weeks I started another one, and I've also just
released a new version of my Gemini server, so I thought it was a good
time to make an announcement :)
It's my primary capsule/blog. I write about things that I find
interesting, usually programming-related stuff but not only, in (an
hopefully correct) English. This capsule is managed using the same
static site generator written in clojure I use for the WWW version of
the site.
This one is new, entirely written in Italian, and it's not a mirror of
the English one. With this capsule I'm trying to do a little experiment
and see how it goes without using a generator: every page is written by
hand and rsync'ed on the server. It's also gemini-only, or
gemini-exclusive if you prefer ;). I'm still writing about things that
I find interesting of course, but it's a bit more "casual".
gemini://gemini.omarpolo.com/pages/gmid.gmi
https://github.com/omar-polo/gmid
gmid was my introduction to Gemini. After discovering the protocol and
reading the specification, I though it was easy enough and I tried to
write a server for it (first commit is dated 2020-10-02). The first
time I used a gemini client was to see if the server was working
correctly IIRC.
Over the time I slowly improved it to match my needs. In these last
two/three weeks in particular I ended up adding a bunch of features,
from virtual host support to a configuration file and various security
features. It's also now usable both as a proper daemon and from the
command line to quickly serve any directory (with automatic certificate
generation).
To the best of my knowledge (although I'll be happy to be proved wrong),
it's the only Gemini server that is sandboxed by default on OpenBSD
(with pledge and unveil), FreeBSD (capsicum) and linux (seccomp), other
than being able to chroot(2) itself.
Other than that, the other features are pretty much what you'd expect:
virtual hosts, configuration file with per-location rules, CGI scripts,
punycode, IRIs, directory listings ecc.
I tagged the v1.5 today, dubbed "Interstellar Overdrive" because why
not.
Thanks,
Omar Polo
--------
Date: Sat, 30 Jan 2021 19:24:25 -0500
It was thus said that the Great Omar Polo once stated:
Other than that, the other features are pretty much what you'd expect:
virtual hosts, configuration file with per-location rules, CGI scripts,
punycode, IRIs, directory listings ecc.
The CGI support seems ... not quite the CGI that I know. It's closer to
SCGI, but even then, it's not SCGI. Looking at the code, any currently
written CGI script for Gemini won't work out of the box. You might want to
think about calling it something else, or work to getting actual CGI or SCGI
support going (SCGI is closer to what you are doing).
-spc
--------
Date: Sun, 31 Jan 2021 09:33:36 +0100
Sean Conner <sean at conman.org> writes:
It was thus said that the Great Omar Polo once stated:
>
> Other than that, the other features are pretty much what you'd expect:
> virtual hosts, configuration file with per-location rules, CGI scripts,
> punycode, IRIs, directory listings ecc.
The CGI support seems ... not quite the CGI that I know. It's closer to
SCGI, but even then, it's not SCGI. Looking at the code, any currently
written CGI script for Gemini won't work out of the box. You might want to
think about calling it something else, or work to getting actual CGI or SCGI
support going (SCGI is closer to what you are doing).
-spc
Thanks for taking the time and read the code. I admit I've not followed
RFC3875 closely. By skimming it I thought "oh, this is simple" and
implemented it straight away.
What I'm currently doing is executing the script with the virtual host
directory as $PWD and setting a bunch of environmental variables. All
the output of the script is then forwarded to the client.
By re-reading RFC3875 I assume that, except for the environment
variables that I'll double check later, I only need to execute the
script in the script directory instead of the vhost one. The RFC
mention passing data in stdin, but it seems only for POST requests and
I'm assuming Gemini ones are ``GET''. It also mention parsing the query
and passing it as argument to the script: this is something interesting,
but I'm not sure how to spilt it? The & doesn't seem widespread here,
so I have to pass the whole query as first argument?
Of course I'd like to have a complete CGI support, and not something
merely closer, so I'll take some time to read how other servers are
handling them, starting from your GLV-1.12556.
I'd like too, as pointed by John Cowan, to have a best-practices or a
companion specification for CGI on Gemini, as RFC3875 seems quite
HTTP-specific, but I don't think I'm the most qualified to write one :D
--------
Date: Sun, 31 Jan 2021 18:28:21 -0500
It was thus said that the Great Omar Polo once stated:
Sean Conner <sean at conman.org> writes:
> It was thus said that the Great Omar Polo once stated:
>>
>> Other than that, the other features are pretty much what you'd expect:
>> virtual hosts, configuration file with per-location rules, CGI scripts,
>> punycode, IRIs, directory listings ecc.
>
> The CGI support seems ... not quite the CGI that I know. It's closer to
> SCGI, but even then, it's not SCGI. Looking at the code, any currently
> written CGI script for Gemini won't work out of the box. You might want to
> think about calling it something else, or work to getting actual CGI or SCGI
> support going (SCGI is closer to what you are doing).
>
> -spc
Thanks for taking the time and read the code.
You're welcome.
By re-reading RFC3875 I assume that, except for the environment
variables that I'll double check later, I only need to execute the
script in the script directory instead of the vhost one. The RFC
mention passing data in stdin, but it seems only for POST requests and
I'm assuming Gemini ones are ``GET''. It also mention parsing the query
and passing it as argument to the script: this is something interesting,
but I'm not sure how to spilt it? The & doesn't seem widespread here,
so I have to pass the whole query as first argument?
You don't split the query. You pass it in, as is, from the request, in
QUERY_STRING. Play around with:
gemini://gemini.conman.org/cgi
It will show all the variables, command line arguments and a breakdown of
the query string.
Of course I'd like to have a complete CGI support, and not something
merely closer, so I'll take some time to read how other servers are
handling them, starting from your GLV-1.12556.
Warning about my server---the CGI implementation also allows one to run
CGI scripts for a webserver (and Apache in particular) so be aware of that.
I'd like too, as pointed by John Cowan, to have a best-practices or a
companion specification for CGI on Gemini, as RFC3875 seems quite
HTTP-specific, but I don't think I'm the most qualified to write one :D
It's not as HTTP-specific as it may seem---the only bit where it's an
issue is the REQUEST_METHOD. My server sets it to "" (as there is no method
for Gemini, and what I think it should be, given RFC-3875 makes it
mandatory); others set it to "GET". Aside from that, it's quite generic.
-spc
--------
Date: Mon, 01 Feb 2021 14:51:42 +0100
Sean Conner <sean at conman.org> writes:
[...]
You don't split the query. You pass it in, as is, from the request, in
QUERY_STRING. Play around with:
gemini://gemini.conman.org/cgi
It will show all the variables, command line arguments and a breakdown of
the query string.
Thanks for providing that page. I played a bit with it while fixing my
CGI implementation and now I believe gmid behaves just like GLV-1.12556
does (minus the argument list). I have to do some changes in order to
access the raw query string when I'm about to execute the CGI script.
One thing that your page doesn't show are the TLS-related environment
variables. I remember you wrote about them in a previous message on
this list.
I built a similar page, hosted at
gemini://gemini.omarpolo.com/cgi/env
> Of course I'd like to have a complete CGI support, and not something
> merely closer, so I'll take some time to read how other servers are
> handling them, starting from your GLV-1.12556.
Warning about my server---the CGI implementation also allows one to run
CGI scripts for a webserver (and Apache in particular) so be aware of that.
> I'd like too, as pointed by John Cowan, to have a best-practices or a
> companion specification for CGI on Gemini, as RFC3875 seems quite
> HTTP-specific, but I don't think I'm the most qualified to write one :D
It's not as HTTP-specific as it may seem---the only bit where it's an
issue is the REQUEST_METHOD. My server sets it to "" (as there is no method
for Gemini, and what I think it should be, given RFC-3875 makes it
mandatory); others set it to "GET". Aside from that, it's quite generic.
-spc
Right, skimming through it gave me the wrong impression. That are
various places were HTTP is blatantly assumed (just grep 404), but
otherwise it seems easily applicable to Gemini.
Thanks
--------
Date: Mon, 1 Feb 2021 09:52:39 -0500
It was thus said that the Great Omar Polo once stated:
Sean Conner <sean at conman.org> writes:
> [...]
>
> You don't split the query. You pass it in, as is, from the request, in
> QUERY_STRING. Play around with:
>
> gemini://gemini.conman.org/cgi
>
> It will show all the variables, command line arguments and a breakdown of
> the query string.
Thanks for providing that page. I played a bit with it while fixing my
CGI implementation and now I believe gmid behaves just like GLV-1.12556
does (minus the argument list). I have to do some changes in order to
access the raw query string when I'm about to execute the CGI script.
One thing that your page doesn't show are the TLS-related environment
variables. I remember you wrote about them in a previous message on
this list.
Ah. To see those, use a client certificate and go here:
gemini://gemini.conman.org/private/cgi-sample
I built a similar page, hosted at
gemini://gemini.omarpolo.com/cgi/env
Cool. But you only set AUTH_TYPE and REMOTE_USER if a client certificate
is present, otherwise, they're not set. Same for the TLS_* variables.
Also, PWD, LANG and LC_COLLATE aren't required (they're not part of the
CGI spec). I included LANG to ensure proper charset usage of any program
executed, LC_COLLATE just because and PATH (not PWD) in case I need to
execute a Unix command from a CGI script.
Thanks
You're welcome.
-spc
--------