Caddy: Caddy 2.0.0 causing redirect loops in WordPress again

[jimsalterjrs]

After installing Caddy 2.0.0 and doing a test Wordpress install, everything worked except for https://site/wp-admin/, which errors out due to a redirect loop.

It's possible to get to the dashboard anyway by going directly to, eg, https://site/wp-admin/themes.php.

This appears to be a regression to #212.

[francislavoie]

Hi! Thanks for trying Caddy!

Please ask your usage questions on the Caddy community forums. We prefer to keep the GitHub issue board for bugs and feature requests. Don't forget to fill out the thread template so we can help you!

[jimsalterjrs]

This was very literally a bug report, complete with a link to the earlier bug it's a regression of—but you do you, boo.

[francislavoie]

You didn't give enough information for us to confirm whether it is a bug. You didn't provide the config you used, or steps to reproduce. We've had plenty of users confirming that Wordpress works just fine for them on the forums.

Here's our bug template if you'd like to re-file it after confirming that the config examples on the forums don't work for you.

---

It's not immediately clear to us what is going on, so we'll need your help to understand it better.

Ideally, we need to be able to reproduce the bug _in the most minimal way possible_. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.

I've attached a template below that will help make this easier and faster! It will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1:

I've also included some helpful tips below the template. Feel free to let me know if you have any questions!

Thank you again for your report, we look forward to resolving it!

Template

## 1. Environment

### 1a. Operating system and version

paste here


1b. Caddy version (run caddy version or paste commit SHA)

paste here


1c. Go version (if building Caddy from source; run go version)

paste here


2. Description

2a. What happens (briefly explain what is wrong)

2b. Why it's a bug (if it's not obvious)

2c. Log output

paste terminal output or logs here


2d. Workaround(s)

2e. Relevant links

3. Tutorial (minimal steps to reproduce the bug)

Helpful tips

1. Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are _always_ relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.

2. Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.

   • 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
   • 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
   • 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.

3. Tutorial: What are the _minimum required specific steps_ someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:

   • Start with an empty config. Add _only_ the lines/parameters that are _absolutely required_ to reproduce the bug.
   • Do not run Caddy inside containers.
   • Run Caddy manually in your terminal; do not use systemd or other init systems.
   • If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
   • Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
   • Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file:

{ ... }

Open terminal and run Caddy:

$ caddy ...

Make an HTTP request:

$ curl ...

Notice that the result is ___ but it should be ___.

[mholt]

@jimsalterjrs I think it was hard to tell your initial post was a bug report, because it contained so little information. Many people are using WordPress successfully with v2.

If you fill out the issue template Francis posted, we can look into it more.

[jimsalterjrs]

1. Environment

1a. Operating system and version

Ubuntu 20.04

1b. Caddy version (run caddy version or paste commit SHA)

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

1c. Go version (if building Caddy from source; run go version)

(go not installed, installed from .deb at the 2.0.0 release here)

2. Description

2a. What happens (briefly explain what is wrong)

After Wordpress installation, everything works except browsing to /wp-admin, which enters a redirect loop.

2b. Why it's a bug (if it's not obvious)

See #212.

2c. Log output

1.5887305067177823e+09  info    http.log.access.log0    handled request {"request": {"method": "GET", "uri": "/wp-admin/", "proto": "HTTP/2.0", "remote_addr": "174.110.160.211:52074", "host": "caddytest.redacted.net", "headers": {"Upgrade-Insecure-Requests": ["1"], "User-Agent": ["Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"], "Accept": ["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"], "Sec-Fetch-Site": ["same-origin"], "Sec-Fetch-Mode": ["navigate"], "Sec-Fetch-Dest": ["document"], "Referer": ["https://caddytest.redacted.net/"], "Cache-Control": ["max-age=0"], "Accept-Language": ["en-US,en;q=0.9"], "Cookie": ["wordpress_sec_fbddd9c239637e56b7840606e9e62ea0=admin%7C1588896156%7Ci1Lhs2x1iFaAloIelldLzrNugYUeUXgfXYZ3Y78W5IE%7Ca6c939a451cd7f2ddde9fa8eb87c8754b1756996bb18f505d98de3658181476b; P_REST=1; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_fbddd9c239637e56b7840606e9e62ea0=admin%7C1588896156%7Ci1Lhs2x1iFaAloIelldLzrNugYUeUXgfXYZ3Y78W5IE%7C05dde1e6981e94b61a7d96d6fe41a0edc382c87f2010b5dacec254b2a6f9394d; wp-settings-time-1=1588723409"], "Accept-Encoding": ["gzip, deflate, br"], "Sec-Fetch-User": ["?1"]}, "tls": {"resumed": false, "version": 772, "ciphersuite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "caddytest.redacted.net"}}, "common_log": "174.110.160.211 - - [06/May/2020:02:01:46 +0000] \"GET /wp-admin/ HTTP/2.0\" 302 0", "duration": 0.010008002, "size": 0, "status": 302, "resp_headers": {"Expires": ["Wed, 11 Jan 1984 05:00:00 GMT"], "Server": ["Caddy"], "Cache-Control": ["no-cache, must-revalidate, max-age=0"], "Link": ["<https://caddytest.redacted.net/wp-json/>; rel=\"https://api.w.org/\""], "X-Redirect-By": ["WordPress"], "Location": ["https://caddytest.redacted.net/wp-admin/"], "Status": ["302 Found"], "Content-Type": ["text/html; charset=UTF-8"]}}

2d. Workaround(s)

Browsing to /wpadmin/themes.php (for example) avoids the redirect loop and gets you to the dashboard succesfully.

2e. Relevant links

212

3. Tutorial (minimal steps to reproduce the bug)

1. new Ubuntu 20.04 VM (I used a Digital Ocean droplet), apt update ; apt distupgrade -y
2. download Caddy .deb from github 2.0.0 release page, dpkg -i *deb
3. caddyfile at /etc/caddy/Caddyfile:

caddytest.redacted.net
root * /var/www/html
log {
    output file /var/log/caddy/access.log
    format console
}
try_files {path} /index.php?{query}&p={path}
php_fastcgi unix//run/php/php7.4-fpm.sock
file_server

1. apt install mysql-server php-fpm php-common php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl php-mysql php-cli php-ldap php-zip php-curl

2. cd /var/www

3. wget https://wordpress.org/latest.tar.gz
4. tar zxvf latest.tar.gz ; mv wordpress html ; chown -R caddy html
5. systemctl restart caddy
6. mysql -udebian-sys-maint -p ; create database wordpress; create user 'wordpress'@'localhost' identified by 'password'; grant all on wordpress.* to 'wordpress'@'localhost'; quit
7. browse to https://caddytest.redacted.net/ and install wordpress
8. browse to https://caddytest.redacted.net/wp-admin, observe redirect loop

[jimsalterjrs]

Note: I see your tips ask for no systemd; running Caddy manually (eg systemctl stop caddy ; cd /etc/caddy ; caddy start) has no impact on the redirect behavior.

[francislavoie]

Did you try without try_files {path} /index.php?{query}&p={path} ?

That shouldn't be necessary, the php_fastcgi directive does a try_files of its own already.

We have a confirmed working example of a Wordpress config here: https://caddy.community/t/example-wordpress/7888

download Caddy .deb from github 2.0.0 release page, dpkg -i *deb

Did you know we have an APT repo? https://caddyserver.com/docs/install#debian-ubuntu-raspbian

[jimsalterjrs]

Did you try without try_files {path} /index.php?{query}&p={path} ?

That shouldn't be necessary, the php_fastcgi directive does a try_files of its own already.

I did not; I used the basic Caddyfile from https://caddyserver.com/docs/caddyfile, which includes that directive. Can confirm; removing that directive does get rid of the Wordpress issue.

Sorry about the bug-report-that-turned-out-not-to-be; googling Wordpress redirect loop caddy, wp-admin caddy, etc led to quite a lot of links that eventually ended up to #212. The links were all quite old, but there was just this major version release, so... yeah, I guessed regression.

Did you know we have an APT repo? https://caddyserver.com/docs/install#debian-ubuntu-raspbian

No, but I'm very happy to see that—several of the top Google results for "install caddy" directs users to pipe curl https://getcaddy.com/ directly to sudo bash, which gives me hives. :)

[francislavoie]

I did not; I used the basic Caddyfile from caddyserver.com/docs/caddyfile, which includes that directive. Can confirm; removing that directive does get rid of the Wordpress issue.

The docs mention that as an example for CraftCMS, which does need that try_files to work around the way it works in contrast to many other PHP frameworks/CMSes that should just work by default with the php_fastcgi directive.

No, but I'm very happy to see that—several of the top Google results for "install caddy" directs users to pipe curl https://getcaddy.com/ directly to sudo bash, which gives me hives. :)

Yeah that's for Caddy v1. Since v2 is so new and quite different, there's not as much resources on the web in comparison yet.

Sorry about the bug-report-that-turned-out-not-to-be; googling Wordpress redirect loop caddy, wp-admin caddy, etc led to quite a lot of links that eventually ended up to #212. The links were all quite old, but there was just this major version release, so... yeah, I guessed regression.

Great to hear it's resolved!