One would hope that this would result in a 404 error being returned to the Web client, but no. Instead, Woo attempts to open this using POSIX, and it doesn't even bother to check the return value (which is -1, with errno = 2 (ENOENT/"No such file or directory")). Instead, the error doesn't get caught until Woo calls (fd-file-size fd) with fd = -1. That invokes SBCL's binding to fstat, which properly checks for fstat's error code and signals a condition. The error comes up not in the browser, but in the Lisp debugger.
I guess I also wouldn't get a 403 error if I tried to serve a file that Woo didn't have permission to read.
The icing on the cake is that this error happens outside of the user-provided request handler, so it
goes straight to the debugger and there is no way to catch it except by modifying Woo's source
files.
One would hope that this would result in a 404 error being returned to the Web client, but no. Instead, Woo attempts to open this using POSIX, and it doesn't even bother to check the return value (which is -1, with
errno= 2 (ENOENT/"No such file or directory")). Instead, the error doesn't get caught until Woo calls(fd-file-size fd)withfd= -1. That invokes SBCL's binding tofstat, which properly checks for fstat's error code and signals a condition. The error comes up not in the browser, but in the Lisp debugger.I guess I also wouldn't get a 403 error if I tried to serve a file that Woo didn't have permission to read.
The icing on the cake is that this error happens outside of the user-provided request handler, so it goes straight to the debugger and there is no way to catch it except by modifying Woo's source files.