1 unstable release
Uses old Rust 2015
0.1.0 | Feb 8, 2016 |
---|
#16 in #cgi
14KB
261 lines
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.