V2: rewrite extensions like v1's http.ext?

[skyfaller (Nelson Pavlosky)]

1. My Caddy version (caddy -version):

v2.0.0-beta9 h1:oILdAOfunJ4ijBN9kOWjFIeH8EufBX/N1pC9HbnwjzU=

2. How I run Caddy:

a. System environment:

Ubuntu 19.10 eoan (GNU/Linux 5.3.0-23-generic x86_64)
on Linode

b. Command:

/usr/local/bin/caddy run --config /etc/caddy/Caddyfile --adapter caddyfile

c. Service/unit/compose file:

[Unit]
Description=Caddy v2 web server
Documentation=https://github.com/caddyserver/caddy/wiki/v2:-Documentation
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
#Restart=on-abnormal

; Do not allow the process to be restarted in a tight loop. If the
; process fails to start, something critical needs to be fixed.
;StartLimitIntervalSec=14400
;StartLimitBurst=10

; User and group the process will run as.
User=www-data
Group=www-data

; Always set "-root" to something safe in case it gets forgotten in the Caddyfile.
ExecStart=/usr/local/bin/caddy run --config /etc/caddy/Caddyfile --adapter caddyfile
ExecReload=/usr/local/bin/caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile

; Use graceful shutdown with a reasonable timeout
ExecStop=/usr/local/bin/caddy stop
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s

; Limit the number of file descriptors; see `man systemd.exec` for more limit settings.
LimitNOFILE=1048576
; Unmodified caddy is not expected to use more than that.
LimitNPROC=4096

; The following additional security directives only work with systemd v229 or later.
; They further restrict privileges that can be gained by caddy. Uncomment if you like.
; Note that you may have to add capabilities required by any plugins in use.
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile:

{
	storage file_system {
		root	/etc/caddy/whatever
	}
	experimental_http3
}

# test page
www.sunrisemovement.dev {
	root * /srv/sunrisemovement.dev/public/
#	try_files {path}.html {path}
	encode gzip zstd brotli
	file_server
}

sunrisemovement.dev {
	redir https://www.sunrisemovement.dev
}

# handcoded site
ri.sunrisemovement.dev {
	root * /srv/sunrisemovement.dev/ri/public
#	try_files {path}/ {path} {path}.php
	encode gzip zstd brotli
	php_fastcgi unix//var/run/php/php7.3-fpm.sock
	file_server
}

3. The problem I’m having:

I just want to replicate Caddy v1’s ext directive: https://caddyserver.com/v1/docs/ext
I want to be able to use a line like the example,
ext .html .htm .php
But let’s start with a simple
ext .php
How does one do that in Caddy v2?

4. Error messages and/or full log output:

5. What I already tried:

I attempted
try_files {path}/ {path} {path}.php
but that seems to have had no effect. A URL like https://ri.sunrisemovement.dev/hubs.php works as expected, but whether the try_files line is commented out or not, visiting a URL like https://ri.sunrisemovement.dev/hubs takes me to some malformed page that doesn’t have the content I expect to see.

What am I doing wrong?

[matt (Matt Holt)]

Thanks for trying v2 while it is still in beta!

I’m guessing that php_fastcgi's hidden behavior is overwriting your own try_files? If you look at the docs, php_fastcgi is short for more logic: Home · caddyserver/caddy Wiki · GitHub

You could try replacing php_fastcgi with that expanded form and customize it to meet your specific needs, since it looks like you want to serve PHP files with an implicit PHP extension in the URL.