Caddy: handle_errors in a site block with a path matcher

[aitva]

This ticket follows a question in the Caddy Forum.

I have the following Caddyfile where I want to handle errors in a site block with a path matcher:

http://localhost:2020/www* {
    root www
    uri strip_prefix /www
    file_server
    handle_errors {
        rewrite * /404.html
        file_server
    }
}

I found that this code does not work and that the handle_errors directive is ignored. To fix it, I have to move the handle_errors to a site block without a path matcher:

http://localhost:2020/www* {
    root www
    uri strip_prefix /www
    file_server
}
http://localhost:2020 {
    handle_errors {
        rewrite * /404.html
        file_server
    }
}

[mholt]

Thanks, what does "this code does not work" mean? How do you know the directive is ignored? What request are you making that yields a different behavior than what you're expecting?

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! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily.

This template 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]

Ping @aitva -- I'd like to work on this but I need more information, when you have a chance. ^

[aitva]

1. Environment

1a. Operating system and version

# Debian Buster
cat /etc/debian_version 
10.5

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

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. Description

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

The handle_errors directive is ignored in a site block with a path matcher.

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

I was expecting the handle_errors directive to work in any site block or an error log to tell me that my configuration was invalid.

2d. Workaround(s)

I worked around the problem by moving the handle_errors directive in a site block without a path matcher, and by rewriting the response according to its path.

3. Tutorial (minimal steps to reproduce the bug)

Create the following Caddyfile in an empty directory:

http://localhost:8080/www* {
    uri strip_prefix /www
    file_server
    handle_errors {
        rewrite * 404.html
        file_server
    }
}

Add an index.html:

<h1>Hello Caddy!</h1>

Add a 404.html:

<h1>Not Found...</h1>

Start Caddy with caddy run and hit the server with the following commands:

curl -i localhost:8080/www/
curl -i localhost:8080/www/notfound

You will be able to get the content of index.html, but not 404.html.

You can work around the problem by moving the handle_errors directive to a new site block in the Caddyfile:

http://localhost:8080/www* {
    uri strip_prefix /www
    file_server
}
http://localhost:8080 {
    handle_errors {
        rewrite * 404.html
        file_server
    }
}

[aitva]

This is the simplest tutorial I could come up with. Tell me if you need anything else.

[mholt]

That's great, thank you.

As soon as I can figure out why VS Code suddenly switched to Go 1.13 and not my existing Go 1.15 install I'll look more into this!

[mholt]

Okay so the problem is that Caddy wasn't restoring the original request parameters before invoking the error handler chain. So the rewrite that stripped /www persisted into the error handler, which must match requests in /www* which of course fails since it was stripped.

I submitted a fix in #3781. @aitva would you please try it out? Then we can merge it and tag a new release.

[aitva]

I just found the time to test and it works perfectly. Thank you for the fix and congratulation for the new release. 👏