Custom 404 page isn't displayed [SOLVED]

1. Caddy version (caddy version): 2.2.1

2. How I run Caddy:

As a Windows service set up by nssm, with the single parameter “run”. The Caddyfile is in the same directory alongside. The user has all necessary permissions

a. System environment:

Windows server 2019

b. Command:

As stated above - a Windows service with the command “caddy run”

c. Service/unit/compose file:

?

d. My complete Caddyfile or JSON config:

####################################################################################
# Top Matter
####################################################################################

{
	email pwh@cassland.org
}

####################################################################################
# Sites
####################################################################################

thrall.cassland.org {
	root * ..\cassland.org\html

	basicauth /CherwellSingers/* {
		cherwell JDJhJDE0JHBoRjNLQUFJTjNoWTMwSC80eVJBZXVFNHg0cnBRZGowNEZBSTJITFh6eURPLlZxbHVDdzA2
	}
	basicauth /Nic/* {
		NBH JDJhJDE0JHo5WGN5eGZ6SkNiRlEwYmtaZjlMMWVMeE1rVWIwZjNCNGhDdXJvRGRjVWRxQ1I5V3ozcWpH
	}
	basicauth /scores2/* {
		pauls JDJhJDE0JGZaLjhRbHVhUWpZZTVMZjhINHNKTGVpTFcyVEpMNDRZMWxTWXl2aEVJejYxREJVOXIzTVlD
	}

    @browsedirs {
    	path /Album*
	    path /images*
    	path /sounds*
    	path /Nic*
    	path /public*scores2
    	path /scores*
    	path /Varicam*
    	path /TascamMod*
    }
    file_server @browsedirs browse
	file_server
	encode gzip
	
	uri /images/QCavi.jpg replace .jpg .php
	uri /images/FireDog.jpg replace .jpg .php
	
	php_fastcgi localhost:9128 #(php74nts)

	log {
		output file .\Logs\CLaccess.log
		format single_field common_log
	}

# Error handler added as workaround for basicauth problem
 	@auth_error {
 		expression {http.error.status_code}==401
 	}
 	handle_errors {
 		header @auth_error {
 			WWW-Authenticate "Basic realm=\"restricted\""
 		}
 		respond @auth_error 401
 	}

    handle_errors {
        @404 {
            expression {http.error.status_code} == '404'
        }
        rewrite @404 /404.html
#       rewrite @404 /New404.html
#       file_server
   }
	
#	handle_errors {
#		rewrite * /{http.error.status_code}
#		reverse_proxy https://http.cat
#	}

}

####################################################################################

3. The problem I’m having:

If I put my 404 page into the URL, it displays fine; if I address a non-existent resource the response is a blank page, with a status code of 0.

4. Error messages and/or full log output:

Access log:

2a02:8010:f01e:1:ec53:7e73:a978:26f6 - - [12/Nov/2020:14:43:48 +0000] "GET /shgjkhgdfj.dshdahg HTTP/2.0" 0 0

Debug line on stderr:

5. What I already tried:

Checked the handle_errors block for correctness, by comparing with other recent examples in the forum. Tried the http.cat alternative with the same effect.

I recall that I tried the cat version with Caddy v2.0.0 when I first tried setting up Caddy 2 some months ago, and it worked then; so I’m wondering if there’s been some regression in v2.2.1, at least in the Windows build.

6. Links to relevant resources:

URLs as in the caddyfile

Thanks for any hints…
Paul

Did you try to uncomment the file_server directive int the handle_errors block?

Yes - I added it, and then commented it out when it had made no difference.

I’ve now also tried the back-level versions I have, both v2.2.0 and v2.0.0rc3, and it doesn’t work in either of them, which puzzles me because I thought it had done. Maybe I just went to the cat site manually.

As I now have two similar reports, I’m wondering whether they are both Windows related - as there seems to be very little love of Windows around here.

Paul

I think one problem might be that you used single-quotes for '404', but single quotes may not be allowed in CEL expressions.

Another issue is that handle_errors is a totally separate handler chain, so you still need to declare root and file_server in there.

I’d also recommend not defining two handle_errors blocks, but instead combine them, because that’s what the Caddyfile adapter does anyways. It’s misleading to read as such because they are ultimately merged.

I’m pretty sure the single quotes came from copying the block out of a forum post. And the additional handle_errors block was left in from the issue in my other thread.

Removing the extra block, adding the file_server and changing to double quotes I now get the output expected. (I forgot to add the root to that block - so is it actually required?)

Thanks!

Paul

This topic was automatically closed after 30 days. New replies are no longer allowed.