Caddyfile:
https://www.waitlisted.dev {
proxy / http://www.waitlisted.dev:3000/
tls wldev.cert wldev.key
}
Expected Behavior:
In my rails applicaiton i would expect my request.host, request.scheme and request.port to be that of the browser.
ex. www.waitlisted.dev, https and 443
Actual Behavoir
My rails app sees the request as its proxied meaning the request headers are being changed by the proxy.
So i get back localhost, http and 80
If anything is unclear i can help clear it up.
HMM after trying to set this up with nginx, i see it behaves the same, i think this may be my issue.
Ok so in nginx the proper way to do this is
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:3000/;
}
Is setting proxy header supported in caddy?
Yeah, use proxy_header: http://caddyserver.com/docs/proxy. You can use request placeholders to set them to be dynamic values like the host and scheme of the request: http://caddyserver.com/docs/placeholders
Closing for now.
Just for interest sake and documentation, I ended up setting these headers which I found in my default Nginx
proxy_header Host {host}
proxy_header X-Real-IP {remote}
proxy_header X-Forwarded-Proto {scheme}
^ Are these sensible defaults? Should we just turn these on by default for the proxy directive?
There is also proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; but that seems to be similar to the X-Real-IP one, though I'm not entirely sure. The value seems different but I don't know what it is exactly.
Perhaps put these into another preset which does a few sensible things rather than just do it? Though tbh, everyone's idea of sensible is different. :)
Bump.
X-Forwarded-ForX-Forwarded-HostX-Forwarded-ProtoOr I guess it wouldn't be X-Forwarded-Host, it would just be Host.
But anyway, seems like these should just default on. I don't know of any instance where A) they shouldn't be used or B) you intend for them not be sent.
i.e. All apps should be checking IP addresses so that they can do any necessary session spoofing checks and whatnot. All apps should know they can set secure cookies and whatnot if the https proto is set.
I guess the Host can have weird edge cases:
https://forwardhq.com/announcements/06-the-curious-case-of-the-host-and-x-forwarded-host-headers
Added the three lines to Caddyfile solved my revproxy problem:
proxy_header Host {host}
proxy_header X-Real-IP {remote}
proxy_header X-Forwarded-Proto {scheme}
Don't know if it should be a problem for some applications, but add as default should be great for many use cases. I added the proxy_header options to my Caddyfile template, so it works for my docker reverse proxy :)
I'll add those 3 lines to the docs as part of an example.
I also want to pass Port
proxy_header X-Forwarded-Port {port}
is there a {port} can use to pass the original port ?
@mholt
Are these sensible defaults? Should we just turn these on by default for the proxy directive?
Maybe this should be considered. Seems that Rails apps require this to work properly.
@andreynering We just merged a PR for a preset called transparent you can use to set all 3 at once very easily. Not everyone wants these headers set this way.
Are there any docs for transparent? It should use X-Forwarded-For instead of X-Real-IP, since it is the defined standard:
X-Forwarded-For: client, proxy1, proxy2
Also, the {host} placeholder is actually yourhost:2015 when running as :2015, which causes problems for any HTTP server downstream if using the config presented here.
Seems there is no clean solution with the placeholders either, since {hostname} is the server hostname, not the request one. Would be nice to have a placeholder {just-the-request-hostname-without-port} to solve this without lots of copy-paste.
@cederberg @wenerme Caddy 0.9 beta has a {hostonly} placeholder that replaces with only the host portion of the Host value.
Also the docs for transparent will land with the release of Caddy 0.9. They're already pushed to the repo, just not in production yet.
As for X-Real-IP please open a new issue about that so we won't lose track of the discussion. Thanks!
Most helpful comment
Just for interest sake and documentation, I ended up setting these headers which I found in my default Nginx