cgid 0.1.0

UCSPI compatible single-script CGI server
Documentation

cgid

cgid is a UCSPI compatible CGI server. It currently supports exactly one script, though there are plans to support a directory.

Usage

Here are a couple examples of using cgid with UCSPI

nosh

#!/bin/nosh
tcp-socket-listen 127.0.0.1 6000
tcp-socket-accept --no-delay
cgid
www/cgi-bin/my-cgi-script

s6

#!/bin/execlineb
s6-tcpserver 127.0.0.1 6000
cgid
www/cgi-bin/my-cgi-script

(other examples are very welcome)

Description

cgid implements a (hopefully reasonable) subset of the CGI protocol. It almost surely has glaring missing features, as I have only run a single program underneath it. Bug reports and patches are warmly welcome.

Known Bugs and Limitations

First response header MUST be Status

As far as I can tell the CGI specification allows the response headers to be in any order. Because all of my applications set the Status first I have not written the code to buffer the other headers before the Status is set. As it stands any headers set before status will be discarded. I expect to resolve this when I get a chance.

SCRIPT_NAME is hardcoded to an empty string

If my reading of RFC3875 is correctly, SCRIPT_NAME should be which script is being run. Given that this server runs exactly one script, I've decided that setting this environment variable is unimportant. If I ever support a directory instead of a single script I'll resolve this.

Only HTTP/1.* is supported

Technically HTTP/1.0 supports HTTP/0.9, which supports responses with no response code or headers. This is not supported for simplicity.

Response Content-Length is unsupported

For both performance and simplicity, the response body is streamed from the application to the client, so the Content-Length is unknown and cannot be sent to the client unless the application set the response header itself.

Esoteric Error

There is one possible error that is impossible to report to the client correctly. Specifically, if there is an error while streaming the response body to the client from the application, returning a 500 Internal Server Error is likely impossible as the applications status has already been set.