reverse_proxy match:a {
to 10.13.13.2:8080
}
reverse_proxy / {
to 10.13.13.2:8083
}
}
3. The problem I’m having:
I am trying to run two proxies
The proxy to server3.zaak-op-orde.nl/ works
It seems I dont understand the rewrite syntax.
The proxy to server3.zaak-op-orde.nl/apiv1 works too but still adds the /apiv1 path,
how do I rewrite that to redirect to 10.13.13.2:8083/… instead of 10.13.13.2:8083/apiv1/… ??
A rewrite is invisible to the client (your browser) because the server is changing the request behind the scenes - effectively pretending it’s a different request.
A redirect is visible to the client because the server effectively tells the client, “wrong address, use this URL instead”, and the browser’s address bar will update with this change.
The service runs on port 8080, if I do a redir I would have to expose Port 8080 to the outside which I do not want. I am looking for the equivalent of apaches:
As far as i can discern Caddy2, with which I am playing, does not support the caddy-v1 ‘without’ subdirective (yet?) Thus I’ll still have to rewrite the url somewhere.
The matcher's path from /apv1 to /apiv1 (assumed typo)
Removed /apiv1 from the rewrite
Consolidated reverse_proxy to a one-liner
According to the v2 rewrite documentation, the syntax is: rewrite [<matcher>] to
So by having rewrite match:a /apiv1 /, Caddy probably dropped the last token and simply rewrote the matched request to /apiv1. Combined with the typo in the matcher means it only rewrote requests for /apv1. Probably not your intended result.
The way the v2 Caddyfile currently is (I say “currently” because I have some last-minute changes planned for the Caddyfile, just need to decide on some things), rewrite is always executed before reverse_proxy unless you set the directive ordering to be something other than the default.
This is a problem I figured using match:a for both would solve. Match the request → rewrite it → reverse proxy it. The request was already “matched” when it was received - so the reverse_proxy can operate on it regardless of the fact the URI has been rewritten before the proxy executes.
If not, how would one proxy only requests to a specific URI but only after rewriting it?
Yes, trimming before proxying is a common use case and was supported in v1 via the without subdirective. Right now it can be done in v2 but only with regex and it must be configured in JSON as the Caddyfile can’t quite achieve this complexity and doesn’t have a dedicated without subdirective to handle it.
Along with some potential changes to Caddyfile route matching / directive ordering, here’s a quick proposal Matt and I thought up for some directives that would enable this behaviour:
Hello, I feel the need to do something about this feature now. Tricky to reverse proxy without this at the moment.
Having a little look at the php directive as an example, I should change the reverseProxy httpcaddyfile.RegisterHandlerDirective("reverse_proxy", parseCaddyfile) to implement the httpcaddyfile.RegisterDirective("reverse_proxy", parseCaddyfile) so I can include various rewrite rules after the matcher but before the reverse proxy handler?
Yes I agree, reading the route proposal makes sense. I was thinking that you could have collected identical matchers and then apply the global ordering within them to collect the handlers together. But having a route looks a lot cleaner and is more explicit.
Can you please help with any tentative release version with this fix, since this is one of the major important requirement for our use case we are trying to build and only the absence of this feature is the blockage.
I went through the example of rewrite and reverse proxy what we are trying to achieve is for example
we have,
/docker/user
/google/user
so if you observe here both the endpoints have URI /user, how do we differentiate request between docker.com and ]google.com as reverse-proxy comes after rewriting.