Nginx location like matching

Help
1

1. Caddy version (caddy version): 2.0.0

2. How I run Caddy:

caddy run --config /etc/caddy/Caddyfile --watch

a. System environment:

Docker

d. My complete Caddyfile or JSON config:

(transparent) {
    header_up X-Forwarded-Host {http.request.host}
    header_up X-Real-IP {http.request.remote}
    header_up X-Forwarded-For {http.request.remote}
    header_up X-Forwarded-Port {http.request.port}
    header_up X-Forwarded-Proto {http.request.scheme}
}

*.infocus.local

root * /etc/caddy/root

log {
    format json
}

handle /cloud/* {
    reverse_proxy {
        to http://infocus-cloud-client
        import transparent
    }
}

handle /infocus/* {
    rewrite /infocus/infocus.application /InFocus.application
    uri strip_prefix infocus/
    reverse_proxy {
        to http://infocus-windows
        import transparent
    }
}

handle * {
    reverse_proxy {
        to http://infocus-web
        import transparent
    }
}

3. The problem I’m having:

When trying to use

Is there an easier way to accomplish what I’m trying to accomplish here. I need /cloud and /cloud/* to match and /infocus /infocus/* to match similar to a location in nginx. I could put two handlers in there I guess or regex. I’m not sure handlers are appropriate in this situation but it seemed to fit the bill.

2

As a side not… this works…

@cloud_match {
    path /cloud
    path /cloud/*
}

handle @cloud_match {
    reverse_proxy {
        to http://infocus-cloud-client
        import transparent
    }
}

I can mark this as the solution, not that this is that verbose, just curious if there’s a ‘better’ way of doing this.

also, I don’t want to match /cloudblah… which is why I don’t do /cloud*

3

You can simplify it to:

@cloud_match {
    path /cloud /cloud/*
}

And in v2.1 it’ll be even shorter:

@cloud_match path /cloud /cloud/*

Also your strip_prefix is probably incorrect, I’m pretty sure it should be /infocus rather than infocus/. There was a time during the betas where that would work, but not anymore.

The infocus rewrite looks unnecessary to me because you already have strip_prefix. Are you doing that because it’s case sensitive? If so, then :+1:

You can also remove the to line and move the upstream right between reverse_proxy and {.

And finally, you can skip passing X-Forwarded-For and X-Forwarded-Proto, those are done for you by Caddy!

4

I am doing that due to case sensitivity, the infocus/ seems to work, don’t remember why I did that, I think I ended up with duplicate / on the end somewhere which I could have accounted for in that spot or done this here, but I’ll look at that again.

Thanks for the other examples!

5

Just to throw another option at the wall here:

rewrite /cloud /cloud/
handle /cloud/* {
  reverse_proxy {
    to http://infocus-cloud-client
    import transparent
  }
}

rewrite /infocus /infocus/
handle /infocus/* {
  rewrite /infocus/infocus.application /InFocus.application
  uri strip_prefix /infocus
  reverse_proxy {
    to http://infocus-windows
    import transparent
  }
}

It’s important to not that this is not the same behaviour as matching both /cloud and /cloud/. This is effectively pretending that a request for /cloud is actually a request for /cloud/, so if your client or upstream expect there to be a difference between the two requests, this example is unsuitable.

Assuming they don’t expect a difference between the two, I like this because it’s a bit neater and doesn’t need a named matcher. :man_shrugging:

1 Like
6

Nice, this actually may work better for certain SEO situations, nice solution!

7

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