Issues w/ handle_errors and reverse_proxy again

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.

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.

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.

1 Like

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. :+1:t2:

Edit 2: and thanks a ton. :slight_smile:

1 Like

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

1 Like

Damn, I even tried searching first too. :weary: Thanks again. :smile:

1 Like