Add support for custom 404 error pages

[muse-sisay]

Fixes #120. Custom 404 page can be passed with --custom-not-found-page

[patrickdappollonio]

This is great, Muse!

The last thing I would ask is, http-server often lets you know if something was configured. To do so, would you mind also printing in the PrintStartup() function the fact you're starting using a custom 404 error page?

Something along the lines of:

if s.CustomNotFound != "" {
    fmt.Fprintln(s.LogOutput, "Using custom 404 page:", s.CustomNotFound)
}

[muse-sisay]

Thank you for the review Patrick. Made changes as requested.

[patrickdappollonio]

Got an extra comment from an acquaintance that uses this project at a well known company which I think we will need to document as an edge case scenario:

When http-server starts, we check if the file is there. Imagine http-server is running for a week, and when you started it, you used --custom-not-found-page=404.html. There could be a situation where the 404 file gets deleted (say, you remounted the directory but for some reason your build process deleted the 404 file) and now you're left wondering what happened that your error page is no longer there.

I think to me that's an acceptable situation. The alternative would be to load the file at the beginning, but that means if you end up updating that file, then the server would need to be restarted for it to take effect.

Today, we have a similar situation with the _redirections file: there is no way to update the redirections file without restarting the server, since the rules get processed on server start.

I do believe though it's acceptable in this case to read a file, and if you deleted it, return the real 404 page (which doesn't have much bells-and-whistles) instead of the customized one.

All that to say, one last change and I'm down to merge this!

[patrickdappollonio]

Tried the new code and unfortunately we'll have a few issues due to s.serveFile():

• The page returns 200 OK since the logic in the code dictates you did read a file
• The page gets etag'd and cached by the browser so subsequent requests will return a 304 Not Modified

On a first request:

$ curl -i http://localhost:5000/this/page/does/not/exists
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 21
Content-Type: text/html; charset=utf-8
Etag: "b21c8405a4ff19828b38b72fe594914e0ad87aaf"
Last-Modified: Wed, 09 Oct 2024 04:24:51 GMT
Date: Wed, 09 Oct 2024 04:28:55 GMT

<h1>404 page!!!</h1>

Then for the follow-up request (emulating a browser that's sending the etag back to the server):

$ curl -i -H 'If-none-match: "b21c8405a4ff19828b38b72fe594914e0ad87aaf"' http://localhost:5000/this/page/does/not/exists
HTTP/1.1 304 Not Modified
Accept-Ranges: bytes
Etag: "b21c8405a4ff19828b38b72fe594914e0ad87aaf"
Last-Modified: Wed, 09 Oct 2024 04:24:51 GMT
Date: Wed, 09 Oct 2024 04:31:39 GMT

The first one, while nice, should come after #120's "custom status codes"... Not right away.

For the second one, I'm torn. For people that want an SPA (see #7), getting the cached copy is actually beneficial (speed improvement) but I'm not sure what's the overall consensus everywhere else. Will have to look at what other http-servers out there do.

To solve the first part (and potentially the 2nd part) we might have to create either a custom version of s.serveFile() or hack the current one. The issue with hacking the current one is that it calls the Go standard library's http.ServeContent() (so it supports range downloads and all that) and that's the function that's overwriting the status code.

We could write a response hijacker that no-ops the status code, since that would have to be solved for #7 as well. I'll cook something up.

[patrickdappollonio]

Last note:

It's missing the documentation, namely updating the help output here: https://github.com/patrickdappollonio/http-server/blob/master/README.md?plain=1#L48-L75

We can avoid a longer documentation in favour of whenever the actual full feature (including custom status codes) happens to be.

[patrickdappollonio]

Looks good to me!