shhttp - Shell HTTP Server
So, what do you do if there's an embedded device you want to serve some content from, which already has a unixoid OS with inetd-style superserver, but no scripting language and no (cross-)compilation environment?
Enter shhttp: An HTTP server written in shell script that understands HTTP/1.0. shhttp is the most painless way to serve a little content from a limited embedded device (router, smartphone, ...).
In about 150 lines (excluding docs) you get a full CGI environment, and a surprisingly fast one as well.
- small: total size less than 8.5 kiB—including docs
- fast: avoids forks and subprocesses
- standalone: doesn't depend on external tools
- compatible: works with bash and busybox-ash as /bin/sh
- flexible: can run on a read-only file system if logging is off
- standards-compatible: HTTP/1.0, CGI/1.1—yes, in theory it can run PHP
- documented: run shhttp manually from the shell to get full documentation
- supports HTTP Basic authentication
- optionally provides Apache-style access logs
- provides helper functions for writing simple shell CGI scripts
- leaves out the exotic bits of HTTP/1.0
- implements CGI/1.1 only, i.e. doesn't even serve plain files (see below for a sample file-serving CGI)
- needs optional tools for some features (bash or date for logging, base64 and md5sum for HTTP Basic authentication)
- needs inetd-style parent server that sets either REMOTE_HOST or TCPREMOTEIP (e.g., stunnel, xinetd, or daemontools)
- Put shhttp into a directory of your choice.
- Create subdirectories "cgi-bin" and "htdocs".
- Put your CGI scripts in "cgi-bin" (see below for samples).
- Make your scripts either executable (if they should run standalone) OR set-GID (if they are shell scripts that should be sourced).
- Point an inetd-style server (recommended: stunnel) at shhttp.
- Access your running server!
There are a few typical security measures implemented. Refer to the built-in docs (run shhttp from a shell to read them) for details. It should be secure, i.e. there is no known way of gaining more information or privilege than your scripts allow.
You should be aware that shell scripting was not intended for this kind of application. This script was written with security in mind to the best of my knowledge, properly quoting everywhere, using neither dodgy nested quotes nor "eval". So while it should be secure and way more reliable than many PHP scripts out there, who knows what pitfalls and bugs different shell versions bear. Do not use it for anything remotely mission critical or privacy relevant.
Because of this, I recommend to use shhttp with stunnel and to require client certificates. That way, shhttp isn't even reachable to unauthenticated users, and the set of trusted users is well under your control. Employing a chroot jail is another sensible security measure, and it's easy, since there are so few dependencies.
Right click, "Save Target As...", you know the routine.