Example for redir?

Caddy v2

DDNS, with Caddy handling subdomains; each subdomain points to a different third party web application running behind my gateway using reverse proxy. One of the subdomains will be a static file server.

 example.ca {
 	root /root/welcome
 	index index.html
 	#log /var/log/example.ca.log
 	encore gzip
 	file_server
 	tls name@example.ca
 }
 
 files.example.ca {
 	root /root/files
 	#log /var/log/files.example.ca.log
 	encode gzip
 	file_server browse
 	tls name@example.ca
 }
 
 app.example.ca {
     reverse_proxy / 10.10.10.10:80 {
         proxy_header Host {host}
         proxy_header X-Real-IP {remote}
         proxy_header X-Forwarded-Proto {scheme}
     }
     #log /var/log/app.example.ca.log
     encode gzip
 	tls name@example.ca
 }

Let’s say example.ca is just my main domain, will just point to a simple static index.html.

files.example.ca will just be a directory of files that get distributed/shared with clients often.

app.example.ca would one of the many apps we will have. I use Caddy for these as reverse proxy to supply https, handle subdomains, etc.

The issue is with app.example.ca. The app behind the proxy doesn’t handle the root subdomain (files.example.ca) very well. It just spits an error. It can’t be changed in the app. You need a URL like app.example.ca/hello/goodbye/#/p to access the web app/interface.

How would I make that Caddy points/redirects app.example.ca to app.example.ca/hello/goodbye/#/p? I’m probably not wrapping my head around the redir directive correctly.

Cheers

Hi @ABotelho, welcome to the Caddy community.

The redir examples located here: redir (Caddyfile directive) — Caddy Documentation

Notably all of these examples are universal (they apply to all requests to the site). It sounds like what you want is to only redirect from the web root (/) to the path your clients need to use to satisfy the upstream server.

What you need to do is use a matcher. All directives support a matcher as their (usually optional) first argument. You want to match the path (to /) before issuing the redirect. Thus, have a look at the path matcher: Request matchers (Caddyfile) — Caddy Documentation

Note also that the example given for a path matcher is the redir directive! It should be easy to adapt to what you need.

If I’m understanding this correctly, it should look something like this?

app.example.ca {
    reverse_proxy / 10.10.10.10:80 {
        proxy_header Host {host}
        proxy_header X-Real-IP {remote}
        proxy_header X-Forwarded-Proto {scheme}
    }
    redir / /hello/goodbye/#/p
    #log /var/log/app.example.ca.log
    encode gzip
	tls name@example.ca
}

Where / is the matcher and /hello/goodbye/#/p is the target?

Spot on! Give it a shot, let us know if it works!

Hi Matt,
Sorry for the delay! It’s been crazy! I finished implementation today, but I’ve noticed Caddy only seems to forward redir / /hello/goodbye/#/p to /hello

It appears to cut out everything after the second forward slash. Do you have any suggestions? It’s critical that it redirects to everything, as the application behind the reverse proxy is picky, and can’t be configured otherwise.

Thanks!

Just had a quick look.

This Caddyfile:

http://:8080 {
  redir / /hello/goodbye/#/p
}

redirects to /hello/goodbye/ - see:

~/Projects/test
➜ curl -I localhost:8080/
HTTP/1.1 302 Found
Location: /hello/goodbye/
Server: Caddy
Date: Thu, 16 Apr 2020 00:12:14 GMT

Why? Remember that this symbol # indicates the start of a comment in a Caddyfile.

Getting around this is fairly easy. The Caddyfile parser counts anything in quotation marks as a single token. If you must issue a redirect to a fragment, encase it in quotes.

http://:8080 {
  redir / "/hello/goodbye/#/p"
}

This produces a better result.

~/Projects/test
➜ curl -I localhost:8080/
HTTP/1.1 302 Found
Location: /hello/goodbye/#/p
Server: Caddy
Date: Thu, 16 Apr 2020 00:12:46 GMT
2 Likes

Oh WOW, that is something I hadn’t even considered!

Just implemented, and it worked wonderfully! I may just end up using quotes like that for all of my redirs for reverse proxying. It might just save me a headache.

Cheers, thanks for the help, you’re a life saver!

2 Likes

I wonder if we should require that comment hashes # are preceded by whitespace… :thinking:

1 Like

Yes, that would be incredibly sensible given the possibility of handling fragments in configuration. It IS a web server, after all. And I think people who don’t put spaces before their comment hashes must be psychopaths :joy: so it should be reasonable to expect a preceding space when we’re not on a new line.

1 Like

Makes sense. I certainly can’t see a scenario where you’d slap you comment up against your config line without a space in between lol

Would it affect comments on their own line?

I have a working patch to solve the # issue, still need to fix caddy fmt to match before I submit a PR.

1 Like

There we go:

3 Likes

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