Caddy redirection help needed

Hello,

I have a wordpress site on a .com domain served via caddy. I want another domain (.de) to be redirected to .com/de/.

What I have so far works without a trailing slash but I have trouble getting the redirection to work with trailing slashes:

abc.de/path > redirected to abc.com/de/path = okay
abc.de/path/ (note the trailing slash here) > redirected to abc.com/path = not okay

Can anybody advise how to fix this: Here is my Caddyfile:

abc.com {
        tls admin@abc.com
        root /var/caddy/abc.com
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock {
                ext     .php
                split    .php
                index    index.php
        }
        internal /forbidden
        rewrite {
                if {path} not_match ^\/wp-admin
                to {path} {path}/ /{query}
        }

}

www.abc.com, abc.eu, www.abc.eu {
        redir https://abc.com{uri}
}

www.abc.de, abc.de {
        redir https://abc.com/de{uri}/
}

Hey @dwehrmann, welcome to the Caddy community.

This should never happen - you’ve configured /de{uri}/, so it should never strip out the hard-coded /de part. If it is, that’s a bug (and a very weird one at that).

This last slash is pretty useless because {uri} is always at bare minimum a single slash /, or if there’s actually more to the URI, you don’t want to throw a trailing slash after a legitimate file extension.

Now, as for the trailing slashes disappearing - usually the culprit for this kind of behaviour, in the source code, is some path.Clean “cleaning” up the trailing slash. But I can’t see this taking place in the redirect code - it should be setting exactly what you specify directly in the Location header.

In my quick testing:

:2015 {
  redir https://example.com/foo{uri}
}

I see the following results:

➜ curl -I localhost:2015
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://example.com/foo/
Server: Caddy
Date: Tue, 07 May 2019 00:13:21 GMT

➜ curl -I localhost:2015/test
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://example.com/foo/test
Server: Caddy
Date: Tue, 07 May 2019 00:13:24 GMT

➜ curl -I localhost:2015/test/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://example.com/foo/test/
Server: Caddy
Date: Tue, 07 May 2019 00:16:25 GMT

In all cases the slash closing the /foo/ element is preserved, and any trailing slash supplied by the client is also preserved.

Hi @Whitestrake, thanks for getting back to me. That was indeed helpful.

I deleted the last slash from my Caddyfile, thanks for explaining.

I think the problem was more related to wordpress (permalink config interfering) than with Caddy.

In case someone else with the same problem stumbles over this thread, the correct wordpress lines are

rewrite {
            if {path} not_match ^\/wp-admin
            to {path} {path}/ /index.php?_url={uri}
    }

No worries. Where’d you get those lines from, out of curiosity?

There’s no need to not_match, the index.php doesn’t need the URI as a query, and you don’t even need to specify index.php at all.

I run WordPress with a Caddyfile like this.

example.com {
  gzip
  root /srv/wordpress
  fastcgi / php:9000 php
  rewrite {
    to {path} {path}/ /
  }
}

Ah, that’s interesting. I found these lines here: How To Install WordPress with Caddy on Ubuntu 16.04 | DigitalOcean

I tried your Caddyfile (without all that match parts) and caddy throws a 502 Bad Gateway error for me.

Probably because in your case, PHP is listening on /var/run/php/php7.0-fpm.sock, not php:9000.

That was an example Caddyfile, you’d need to change the root and fastcgi directives to suit.

Bit unfortunate about the Digital Ocean community tutorials - DO’s website gives some less-than-accurate instructions a veneer of authenticity, and I think that the whole not_match and the URI query are a case of citogenesis…

Ha, I changed the root directive but of course I did forget changing the php part. It works now without the rewrite part. Yes, I agree with the DO tutorials, however this one seemed to work just fine.

Thanks for clearing that up! Feels better with less clutter …

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.