V2: How to achieve custom 404

I am experimenting with Caddy as the Caddy v2 documentation page has increased.

I noticed that a Custom 404 page can be realized with the current specifications.

Caddyfile:

example.net.eu.org {
    root * D:\Dropbox\Caddy\example.net.eu.org
    uri_replace / / /index.html
    try_files {uri} 404.html /404.html
    templates
    encode gzip
    file_server
}

This simply outputs 404.html if the file does not exist,
but try_files also invalidates index.html, so I supplemented it with uri_replace.
example.net.eu.org/<directory>/index.html does not work in this Caddyfile. Something is missing.

The template can add any header, can I add http status to this?
Of course, here we assume that 404.html returns http status 404.
(You may be happy to stay at 200)

If you have another way to achieve custom 404, please share it by reply.
It may later implement the status equivalent of v1 in the Caddyfile, but will be useful later.

Thanks for using v2 while it’s in beta, @balloon! Caddy 2 doesn’t yet have error handling exposed through the Caddyfile, but it will before the stable release.

In the meantime, you can use the JSON configuration: https://caddyserver.com/docs/json/apps/http/servers/errors/

1 Like

Yes. I have already seen that in other posts. But what I’m trying to do seems to be usable later.

Caddyfile seems to be able to solve this:

example.net.eu.org {
    root * D:\Dropbox\Caddyfile\example.net.eu.org
    @index {
       path_regexp .*/$
    }
    uri_replace @index {path} {path}index.html
    try_files {uri} 404.html /404.html
    templates
    encode gzip
    file_server
}

but I am dissatisfied with using named matcher and path_regexp.:unamused:

1 Like

Have there already been commits lately that expose error handling to Caddyfile v2 lately? I also really like Caddy v2 to serve a custom 404 page just like v1 did with the errors directive:

errors {
	404 404.html # Not Found
	500 500.html # Internal Server Error
}
2 Likes

Yes, but it’s not documented yet because I’m going to clean it up / refine it (possibly breaking changes) before the release candidates. Use the handle_errors directive for now. Just put your routes in a handle_errors block. But be aware I might change that before v2…

1 Like