Basicauth causes site to return 301 or 308

Help
8

OK, I’m getting much closer.

First, this is not a Windows issue - I have built a Linux server and (with much trouble, caused by SELinux) got Caddy running on it.

I then built up my Caddyfile bit by bit. And the addition which stopped basicauth working was my handle_errors directive.

If I include:

	handle_errors {
		@404 {
			expression {http.error.status_code} == "404"
		}
		rewrite @404 /404.html
		file_server
	}

then I get the blank page with no authorisation popup, as I’ve reported above, and the access log shows that the response was “0”.

If I include

	handle_errors {
		rewrite * /{http.error.status_code}
		reverse_proxy https://http.cat
	}

then the log contains a stream of errors:

192.168.1.74 - - [16/Nov/2020:12:31:56 +0000] "GET /404/ghost HTTP/2.0" 301 178
192.168.1.74 - - [16/Nov/2020:12:31:56 +0000] "GET /404/ghost HTTP/2.0" 301 178
192.168.1.74 - - [16/Nov/2020:12:31:56 +0000] "GET /404/ghost HTTP/2.0" 301 178
etc

and Firefox reports: “The page isn’t redirecting properly”. This loop occurs both for accessing a basicauth-protected page and for an actual 404.

As a reminder of the context, this is my complete Caddyfile:

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

{
#	debug
	email pwh@cassland.org
}

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

#cassland.org, www.cassland.org {
#thrall.cassland.org {
pen2.cassland.org {

#	root * ..\cassland.org\html
	root * /var/www/html/cassland_org
	
	uri /images/QCavi.jpg replace .jpg .php
	uri /images/FireDog.jpg replace .jpg .php

	basicauth /CherwellSingers/* {
		cherwell JDJhJDE0JHBoRjNLQUFJTjNoWTMwSC80eVJBZXVFNHg0cnBRZGowNEZBSTJITFh6eURPLlZxbHVDdzA2 # xxx
	}
	basicauth /Nic/* {
		NBH JDJhJDE0JHo5WGN5eGZ6SkNiRlEwYmtaZjlMMWVMeE1rVWIwZjNCNGhDdXJvRGRjVWRxQ1I5V3ozcWpH # yyy
	}
	basicauth /scores2/* {
		pauls JDJhJDE0JGZaLjhRbHVhUWpZZTVMZjhINHNKTGVpTFcyVEpMNDRZMWxTWXl2aEVJejYxREJVOXIzTVlD # zzzx	}

	encode gzip
	
#	php_fastcgi localhost:9128 #(php7nts)
	php_fastcgi localhost:9000 #(php-fpm)

	@browsedirs {
		path /Album
		path /Album/*
		path /images
		path /images/*
		path /sounds
		path /sounds/*
		path /Nic
		path /Nic/*
		path /scores
		path /scores/*
		path /scores2
		path /scores2/*
		path /Varicam
		path /Varicam/*
		path /TascamMod
		path /TascamMod/*
	}
	file_server @browsedirs browse
	file_server

	handle_errors {
#		Attempt to make basicauth work in Windows:
#		@401 {
#			expression {http.error.status_code} == "401"
#		}
#		header @401 {
#			WWW-Authenticate "Basic realm=\"restricted\""
#		}
#		respond @401 401
        
#		@404 {
#			expression {http.error.status_code} == "404"
#		}
#		rewrite @404 /404.html
#		rewrite @404 /New404.html
#		file_server

#		Use cat server messages:
		rewrite * /{http.error.status_code}
		reverse_proxy https://http.cat
	}

	log {
#		output file .\Logs\CLaccess.log
		output file /var/log/caddy/CLaccess.log
		format single_field common_log
	}
}

I now see this has been reported before (at least, the reverse_proxy version), with what seems to me an inconclusive response: this report here. But note that in my original case the reverse_proxy shouldn’t be invoked; the problem seems more to be that handle_errors is picking up a status set by the basicauth and preventing it being passed on to the client correctly. Equally, the handle_errors directive works until a basicauth is added to the Caddyfile - this stops the handle_errors working, even when the basicauth is not invoked.

Paul