Closed misalcedo closed 8 months ago
I already have a basic CGI server. Clearing the task list and starting a new one.
I finished implementing support for loading any CGI script from the CGI bin directory. Also, I added a document root to be used to resolve relative CGI bin paths, used as working directory for scripts and for path translation.
The assert.cgi script now validates all non-protocol meta variables are passed correctly.
I now pass the server name from the command line (resolved on server start) to the script.
The script name and server name are both passed to the script. However, script URI also requires knowing the scheme.
The plan is to have the server context maintain a scheme variable. The scheme will just be "http" for now and will support "https" once I add TLS support.
The script now gets a valid script URI verified in assert.cgi.
The query string is now parsed as command-line arguments.
Hyper does not discard bodies on HEAD requests. I created a router that implements Service (instead of the CGI client). The router drops the body on HEAD requests and maps io errors to HTTP status codes.
I tried passing a null stdout to the child process, but that means the script can't set any headers which is the entire point of HEAD requests.
Implemented a static asset server that loads files fully into memory before returning the contents.
The server prevents loading of files with the cgi
extension statically (i.e. must be loaded dynamically).
I added tests for all 4 types of responses, including local redirection. The local redirection test currently fails since I just return an error response saying "unsupported".
Added logic to ensure redirects have empty bodies.
I added support for local redirects by moving the body collection logic to the router. Then, the CGI script is invoked with a body of Bytes
, which is cheap to clone allowing replaying of the request body. Finally, I updated the request's URI's path and query from the location header and was able to get both local redirect tests to pass.
Closing in favor of tracking improvements in another issue.
The CGI protocol is a great way to map HTTP requests to system processes (environment variables, stdin, stdout, stderr and arguments). Using the same protocol we can map HTTP requests to WASI invocations.
Documentation