Dear nginx@,
I’m not sure if this has already been done before and to what extent,
but I’d like to demonstrate that a whole web-service “portal” can be
written exclusively in nginx.conf, without any php, perl, python, java
or cgi, or even any files external to nginx.conf.
Introducing http://mdoc.su/ .
The service provides deterministic URL tinyfication / URI shortening for
BSD manual pages.
How does it work?
It operates on 3 inputs: the operating system, the section and the
manual page.
For example, to see the kqueue(2) manual page from FreeBSD, you can
point your browser to kqueue , or mdoc.su/f/kqueue.2,
or mdoc.su/f/2/kqueue, or you can even use “FreeBSD” or “freebsd” in
place of “f”, as in, http://mdoc.su/freebsd/kqueue etc.
When nginx receives the request, it quickly gets re-written, and a
redirect to FreeBSD Manual Pages is produced.
Same for OpenBSD, NetBSD and DragonFly BSD, of course.
Forgot how to specify timeouts for ssh(1)? ssh(1) - OpenBSD manual pages
The site even has a start page, also exclusively through nginx.conf, and
supports Google Webmaster Tools site verification, through the “HTML
file upload” option, through nginx.conf (of course!). (BTW, the format
of those verification files has changed a couple of years back, where
special and unique file content is now required, and the new file format
itself is a very-very big secret, that Google will not share with anyone
without a file-save-capable browser or an NDA! Reverse-engineered with
nginx.conf, too!)
Notice that the whole ordeal runs entirely out of nginx and is
controlled by an nginx.conf file, which I think is pretty nifty. 
The source code is available at GitHub - cnst/mdoc.su: Deterministic URL shortener for BSD manual pages, written in nginx.conf , and
might also be attached to this message.
Comments, questions and suggestions are very welcome.
P.S. Prior multi-part message was a result of trying to hand-edit
“Content-Disposition: attachment;” to “inline” through E /
“edit-headers” in mutt, after pasting the message from SeaMonkey.
But mail.content_disposition_type set to 0 should now work much better.
Best regards,
Constantine.