Issues w/ handle_errors and reverse_proxy again

[xnaas]

1. Caddy version:

Built from master a few minutes ago: v2.2.2-0.20201118231455-12cc69ab7ade h1:Pss1c1toELBy8jbzQGQpD327MkPLS+4XfWptLzjkQQM=

My normal setup is currently on: v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

2. How I run Caddy:

My normal setup involves docker and such, but this example is just using xcaddy to build from master, running caddy with ./caddy run, and accessing the webserver via 192.168.1.101:9090 from another machine on LAN.

a. System environment:

$ uname -a
Linux xnaasSRV 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux

Again: normally this is all dockerized and such, which is where I first noticed the issue. But I’ve build from master and am running more “normally” for this testing to demonstrate that the issue is not my specific setup.

b. Command:

./caddy run

c. Service/unit/compose file:

N/A # Not relevant at this time

d. My complete Caddyfile or JSON config:

{
  debug
}

:9090 {
  root ./test/
  handle_errors {
    rewrite * /{http.error.status_code}
    reverse_proxy https://http.cat
  }
  file_server browse
}

3. The problem I’m having:

This setup is not working as it used to. A normal workflow previously:

1. Go to 192.168.1.101:9090
2. Everything works fine
3. Go to 192.168.1.101:9090/nothere
4. Get https://http.cat/404 displayed from reverse_proxy

Unfortunately, now something is doing something janky. Instead, I end up getting sent in a redirect loop that causes every major browser to error out. It seems like it’s trying to point me to 192.168.1.101:9090/private/?r=<spamhere> and/or 192.168.1.101:9090/404?r=<spamhere>.

4. Error messages and/or full log output:

Here’s an example from debug logging when trying to go to 192.168.1.101:9090/nothere: https://pastebin.com/gVafzx41 (the bit at the end is just me hitting ctrl+c to kill the process).

5. What I already tried:

Other than removing the handle_errors, I can’t think of what to try, thus I’ve come here seeking assistance.

[xnaas]

I first noticed this issue…maybe within the last week or two? It’s possible something changed on http.cat’s end. I don’t really know how to diagnose that, though.

[francislavoie]

Hadn’t we determined that you need to use header_up Host http.cat as a reverse_proxy subdirective? Maybe I’m thinking of a different thread.

What happens when you make the request with curl -v? That should show the headers in the request, it’s easier to follow. You can use curl -vL to follow the redirects.

[xnaas]

Hadn’t we determined that you need to use header_up Host http.cat as a reverse_proxy subdirective? Maybe I’m thinking of a different thread.

I don’t know anything about it, but I can definitely add a header now if that’s needed.

What happens when you make the request with curl -v? That should show the headers in the request, it’s easier to follow. You can use curl -vL to follow the redirects.

Without adding any header: https://pastebin.com/KpnuFBRF

Edit: with that header added, everything appears to be good now.

Edit 2: and thanks a ton.

[francislavoie]

Hah, yep, it was someone else doing the exact same thing:

Error handling using http.cat and reverse proxy not functioning (or I'm stupid, one of the two)

I think you might need to override the Host header when proxying to it. It likely expects the domain to match. By default, Caddy passes the Host of the original request through. handle_errors { rewrite * /{http.error.status_code} reverse_proxy https://http.cat { header_up Host http.cat } }

[xnaas]

Damn, I even tried searching first too. Thanks again.