V2: Rewrite and try_files

[atonse (Ashish Tonse)]

1. My Caddy version (caddy -version):

v2.0.0-beta11 h1:NVHnPAdZPt6OUBMltUMe2DWVsyYRbeE6NxhCm3AjGT8=

2. How I run Caddy:

systemd unit file

a. System environment:

systemd

b. Command:

Same as Caddy reference.

c. Service/unit/compose file:

Same as Caddy reference.

d. My complete Caddyfile:

api.qa.example.com {
  reverse_proxy * {
    to localhost:4100
  }
}

qa.example.com {
  try_files {path} /index.html

  file_server / {
    root /var/www/example/qa/static
  }
}

3. The problem I’m having:

This is what I’m trying to do:

My root dir has only two files:
logout.html
index.html

I want /logout.html to serve logout.html
I want every other path to serve index.html

4. Error messages and/or full log output:

Please DO NOT REDACT any information except passwords/keys.

5. What I already tried:

I tried matchers. I tried rewrite with “r” and a regexp like /.*logout\.html/

6. Links to relevant resources:

[matt (Matt Holt)]

Thanks for trying v2 while it’s still in beta!

What about your configuration doesn’t work? You left question 3 unfinished I think, and question 4 is blank…

(in the future, please don’t redact domain names - we have good reasons for that)

[matt (Matt Holt)]

FWIW @atonse, this config works as expected:

localhost

root * /Users/matt/Desktop/atonse
try_files {path} index.html
file_server

The only two files in the atonse folder are index.html and logout.html.

[atonse (Ashish Tonse)]

That did it. Thanks for taking the time to reply. I wouldn’t have arrived at that combination in a million years at least by looking at the docs. Can I suggest adding this particular example to the docs?

[matt (Matt Holt)]

That’s good, but… isn’t it the same as your config? I was trying to say that I couldn’t reproduce the problem. I’m glad my config works, but I would think they both should work, no?

@atonse

Can I suggest adding this particular example to the docs?

The v2 Caddyfile isn’t yet documented (except some blurbs in that awful wiki page for now), which is why it was hard to find documentation for it. Yeah, I’ll be writing up docs this and next week.

[matt (Matt Holt)]

Oh! Sorry, I know what happened. (I’ve been sick so comprehending is a little slow lately.)

This:

file_server / {
  root /var/www/example/qa/static
}

means that the site root is only known to the file server.

This:

root /Users/matt/Desktop/atonse

sets the root folder for the whole site. The try_files directive needs to know the root of the site, otherwise it assumes current working directory.

Will definitely make that clear in the new docs, don’t worry.

[atonse (Ashish Tonse)]

Good point. Also I’m not entirely sure what the “*” in the first root arg actually does. Can you set multiple roots? Conceptually that goes against the word “root” though.

[atonse (Ashish Tonse)]

Also, conceptually, I had tried to add try_files to the file_server block (because I’m asking it to try files to serve, in a file server). And that failed too.

Some of it is just the words not fully jiving in my head.

I didn’t know you could just say “file_server” for the whole site and have root outside of it.

[matt (Matt Holt)]

@atonse

Also I’m not entirely sure what the “*” in the first root arg actually does.

That’s a matcher token. You can read more here, for now: GitHub - caddyserver/caddy: Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

Although part of that is a bit outdated. Next week, matchers are changing a bit (improving).

Basically, a matcher token makes that directive selective to only requests which match the matcher.

A * is a wildcard matcher. It’s implicit and can usually be omitted entirely, except that the next argument also looks like a path matcher. A path matcher starts with / and is the most common kind of matcher, so it’s a special case in that it can be defined inline. Other matchers can take the form @matcher_name which are defined in their own block. This is helpful when matching on some property of the request other than the path.

@atonse

Can you set multiple roots? Conceptually that goes against the word “root” though.

In Caddy 2, you sure can. You can set a different root depending on the kind of request you get (like its path, or anything else about it). It still means “root of the site” or “file root” so it’s still in harmony with the word.

@atonse

Also, conceptually, I had tried to add try_files to the file_server block (because I’m asking it to try files to serve, in a file server). And that failed too.

You can’t arbitrarily nest directives inside other ones, unless the directive is specially designed to have other directives within it.

@atonse

I didn’t know you could just say “file_server” for the whole site and have root outside of it.

Yeah, we’re not nginx … contexts aren’t as much of a thing in the Caddyfile. The Caddyfile is much simpler, but also about as powerful.

[atonse (Ashish Tonse)]

Funny, thanks for the explanations. I was aware of matchers and tried them but it always felt like overkill for what I was trying to do (essentially try_files).

I’ve been using Caddy since the beginning, especially for dev, and am still learning new things. Keep up the good work.

[matt (Matt Holt)]

Thanks. Yeah, the Caddyfile needed some polish and now it’s getting it, so it’ll be as easy to use as in v1 but even more powerful and flexible. Tricky to strike that balance. I hope you like the improvements.