💾 Archived View for gemi.dev › gemini-mailing-list › 000647.gmi captured on 2023-12-28 at 15:50:33. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
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 :) => gemini://gemini.omarpolo.com 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. => gemini://it.omarpolo.com 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
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
When I asked about CGI compatibility, the answer was that different servers did it differently anyway. That's probably something we should fix in the best-practices document. On Sat, Jan 30, 2021 at 7:24 PM Sean Conner <sean at conman.org> wrote: > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210130/a099 513d/attachment.htm>
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
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
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
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
---