fileserver: Better handling of HTTP status override

[francislavoie]

Just something I noticed when reading through the code; I think the io.Copy was a remnant of an older version of that code. I don't see a reason why we don't just let it fall through and serve the file with http.ServeContent normally. More consistent that way.

Also, I hoisted the status_code override logic above the error handler detection bit, because then it allows for overriding the status code during error routes. Not necessarily that likely to be useful, but it's more correct. (Reminder that the first w.WriteHeader() wins, subsequent ones have no effect). Marking this as a bug just for this reason, but it's barely worth discussing as a bug 😅.

Edit: So calling w.WriteHeader() ourselves makes the w.Header().Set() operations in http.ServeContent not actually work correctly, which isn't ideal.

After a bit of googling, I found a great solution, by wrapping the ResponseWriter to intercept the w.WriteHeader() call that http.ServeContent does to write the header we want instead.

[mholt]

Thanks, this LGTM.

You did test this, right? 😄

[francislavoie]

Yep, with this Caddyfile, and a 404.html file in $PWD

{
        admin off
        debug
}

:8883 {
        root * .

        handle_errors {
                rewrite * /404.html
                file_server
        }

        file_server
}

Request to http://localhost:8883/ serves /404.html with status 404, and Last-Modified header is set (wasn't before)

Before:

After:

[mholt]

Perfect, thanks so much!