commit - 46af8c6cfe1f1ec15d93bc58791f4596c610785b
commit + 286c4f40a54be609d0c03e8229826d9fee5ad8d3
blob - 7329daecfa31542ea1c5939694e172aae46ef26e
blob + fe104e1760084467733e0b25860d2f9ee386660c
--- README.md
+++ README.md
## Features
- IRI support (RFC3987)
+ - punycode support
- dual stack: can serve over both IPv4 and IPv6
- CGI scripts
- (very) low memory footprint
- small codebase, easily hackable
- virtual hosts
- - rules per-location
- - directory listings
- - mime types configurable
- - index file configurable
+ - per-location rules
+ - optional directory listings
+ - configurable mime types
- sandboxed by default on OpenBSD, Linux and FreeBSD
- chroot support
connection per-second you'd probably want to run multiple gmid
instances behind relayd/haproxy or a different server.
+
+## Internationalisation (IRIs, UNICODE, punycode, all that stuff)
+
+Even thought the current Gemini specification doesn't mention anything
+in this regard, I do think these are important things, so I tried to
+implement them in the most user-friendly way I could think of.
+
+For starters, gmid has full support for IRI (RFC3987 --
+Internationalized Resource Identifiers). IRIs are a superset of URI,
+so there aren't incompatibilities with URI-only clients.
+
+There is full support also for punycode. In theory, the users doesn't
+even need to know that punycode is a thing. The hostname in the
+configuration file can (and must be) written with proper UNICODE, gmid
+will do the rest.
+
+The only missing piece is UNICODE normalisation. gmid doesn't
+do that (yet).
+
+
## Building
gmid depends on a POSIX libc, OpenSSL/LibreSSL and libtls (provided