💾 Archived View for alexey.shpakovsky.ru › gemlog › on-http-vs-gemini-simplicity.gmi captured on 2023-11-14 at 07:53:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-06-03)
-=-=-=-=-=-=-
Dunno if it was Ainent's intention or not, but the words about only 2 HTTP servers triggered me so I couldn't stop myself from replying.
The simplicity of Gemini - by Ainent
While I agree with overall idea of the article and its conclusions, I still have to answer two points.
Contrast this with HTTP, which has, what, 2 servers? Perhaps there are a few more, but not many.
First, if you look at Wikipedia's list of web server software, you notice a table with (many) rows. As of writing, 9 of listed servers had last release date less than a year ago, 12 more - within two years.
Comparison of web server software
Second, same Wikipedia page hints that many programming languages have some kind of web server built-in, and indeed there are several collections of shell one-liners showing how to run them:
Big list of http static server one-liners - by willurd
Simple command line HTTP server
While not very feature-rich, they're servers, indeed.
Try reading the HTTP spec and see if you think you could just whip out a compliant server (or client) in your free time. Good luck.
HTTP server - note that I'm not talking about HTTPS - isn't that hard, actually. Indeed, there are many optional things like compression, websockets, using UDP instead of TCP (but that's only for HTTPS), or serving several hosts from one server, but they're optional, so if your server doesn't support them - it still will be able to serve files. Yes, at this point it will be as featureful as your simple gemini server, but that's the point.
I would even go as far as to say that simplest HTTP server is even simpler to implement then a simplest gemini server, due to lack of encryption. Simplest HTTP server doesn't have to do anything more fancy than maybe extract URL from first line of request and react to it. Here is one written in bash:
busybox nc -lk -p 1234 -e /bin/sh -c 'printf "HTTP/1.0 200 OK\r\n\r\n"; sed "/^.$/q"'
It just prints back the client request.
Of course, if your site has more than a few visitors per second (above 1-liner could process 30 requests per second in my testing), you might want to look into more performance-oriented server which doesn't spawn two processes on each request, and maybe can process several requests in parallel... But for small servers with not-so-many visitors this might be enough.
It seems that neither -k, nor -e are universally present switches for all version of netcat
Indeed I'm using this particular nc version:
$ busybox nc --help
BusyBox v1.34.1 () multi-call binary.
Usage: nc [OPTIONS] HOST PORT - connect
nc [OPTIONS] -l -p PORT [HOST] [PORT] - listen
-e PROG Run PROG after connect (must be last)
-l Listen mode, for inbound connects
-lk With -e, provides persistent server
<...>
Other implementations might miss some of the used options. Those might find this wiki page useful:
Netcat § Setting up a one-shot webserver
So yes, writing an actual HTTP server in bash might be a bit harder than I presented a t first :) The hardest part being how to open a (listening) socket and read from it. Also note that I had to use sed instead of plain cat to pipe input to output - because cat wasn't closing input (?) and connection was hanging. So yes, bash is probably not the most appropriate language to write HTTP servers :)
Where the real complexity lies is in the browser (and that's not a secret). You don't need a powerful browser to read responses produced by the 1-line server above. Actually you can just curl it and see result on your terminal.
But if you want to look at slightly more fancy pages - your browser indeed must be more advanced, supporting HTML and CSS (used on the pages you want to look) and javascript (if your pages need them). If you want to watch some videos - your browser must understand all (or some of) their formats and know how to decode and play them. If you want to watch some copyright-protected videos (hi Netflix) - your browser must support DRM.
Even just properly parsing HTML tags might be non-trivial task given that not all people compose them correctly.
So in _that_ I agree with Ainent - gemini _text format_ is much simpler (and thus easier) than HTML, making gemini _clients_ easier to implement. And yes, once implemented, you can always be sure that your client will render any URL starting with gemini://. Maybe with exception of minor details like _underline_ or latest Unicode symbols 🫰. Unlike with HTML browsers - you never know what clicking an http:// link will bring you and if it will be compatible with your browser.
----
Be aware that I also might be wrong in some regard (after all, unlike Ainent I've never implemented any kind of socketing framework), so please feel free to correct me - privately or publicly.