When a CGI script is configured to be at the root of a domain -- when the whole website is served from one CGI script -- cgi/src/lib.rs:304:21 panics:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: http::Error(InvalidUri(Empty))',
/build/foo-0.1.0-vendor.tar.gz/cgi/src/lib.rs:304:21`
It looks like this is caused by SCRIPT_NAME being empty. There isn't a script name when the script is serving the whole domain.
I found this note, which seems to be interpreting RFC 3875 section 3.3, which makes a promise that
http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO will always be an accessible URL that points to the current script
So if the script is serving http://example.com:80/ , there's only the one / character at the end there to be split between SCRIPT_NAME and PATH_INFO. Apache puts it in PATH_INFO -- it calls the CGI script with PATH_INFO=/ and SCRIPT_NAME= (empty). An empty SCRIPT_NAME causes version 0.6.0 of this library to panic, but is a valid invocation of a CGI script.
When a CGI script is configured to be at the root of a domain -- when the whole website is served from one CGI script -- cgi/src/lib.rs:304:21 panics:
It looks like this is caused by
SCRIPT_NAMEbeing empty. There isn't a script name when the script is serving the whole domain.I found this note, which seems to be interpreting RFC 3875 section 3.3, which makes a promise that
So if the script is serving
http://example.com:80/, there's only the one/character at the end there to be split between SCRIPT_NAME and PATH_INFO. Apache puts it in PATH_INFO -- it calls the CGI script withPATH_INFO=/andSCRIPT_NAME=(empty). An empty SCRIPT_NAME causes version 0.6.0 of this library to panic, but is a valid invocation of a CGI script.