I need to set equivalent of header_upstream in caddy v1 when doing reverse proxy.
4. Error messages and/or full log output:
curl -X POST "http://localhost:2019/config/apps/http/servers/example/routes/0/handle/0/headers/" -H "Content-Type: application/json" -d'{"request": {"set": {"Host": "dev.myhost.com"}}}'
running: loading app module 'http': provision http: server example: setting up server routes: loading handler module in position 0: loading module 'reverse_proxy': decoding module config: http.handlers.reverse_proxy: json: cannot unmarshal string into Go struct field HeaderOps.headers.request.set of type []string
Oh, sorry. I’m not setting it in caddy.json actually. So the idea is to set the Host header for upstream dynamically so that I can easily point it to different app without changing the whole upstream definition.
Do you need a different value per-request? Something like a value of "{http.request.host}", to pass the hostname of the incoming request through to the upstream one?
No. So the use case actually to build something similar to ngrok. Let say I point *.myngrok.com to this caddy server. I want to allow my user to have domain like sub1.myngrok.com being forwardded to their local server. Their local server might be expecting different Host header (not sub1.myngrok.com) so they should be able to set that when adding new forwarding. The user then would do reverse ssh port forwarding from the server to their local, such as:-
To add new forwardding rule that will forward to their local server. Currently I’m using caddy1 but limited to just single subdomain as adding new config to Caddyfile is non-trivial. But after looking at caddy2 dynamic configuration I thought maybe it possible to this easily now.
Okay. Right. So, to answer the first question: headers are a map of string to []string, because you can have header fields that are repeated, i.e. with multiple values. So your POST above looks correct.
And by doing a GET after that, can you confirm that this is your current, running config?
Oh dear. I’m so sorry. The header was actually set correctly and passed to upstream. I should have checked that first instead of just basing on the result that I’m not getting the website I was expecting to see.
So it’s totally my fault. The Host to set was wrong, not the one I’m expecting on upstream. Again, I’m sorry for wasting your time. I’ll try to make it up by doing some write up (or fix the docs to be more clear) on this feature.