Add support for Forwarded header (RFC 7239)

[0az]

RFC 7239 specifies a Forwarded header, which is intended to replace X-Forwarded-*.

It would be great if Caddy supported this.

Ref:

• https://tools.ietf.org/html/rfc7239
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded

[mholt]

Thanks for the request.

What is your use case for this?

The Go team tried to drill down on this a few years ago but the answers were either missing or unsatisfactory: golang/go#20526

[0az]

Thanks for the quick response.

Honestly, it's more of a "nice to have", with a use case of replacing the quasi-standardized X-Forwarded-For/-Host/-Proto/-Scheme. I can afford to do this in my environment (Caddy in front of a small collection of services).

---

Some research on the topic:

I found @c960657's more comprehensive https://c960657.github.io/forwarded.html immediately after I finished making the list below. 😅

Relevant issues/tickets:

• https://bz.apache.org/bugzilla/show_bug.cgi?id=58001
  • ❌ Implemented, not merged
• https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/
  • ❌ Not implemented, no issue
• proposal: net/http/httputil: support RFC 7239 Forwarded header in ReverseProxy golang/go#20526
  • ❌ Not implemented, issue closed
• Support "Forwarded" header instead "X-Forwarded-For" traefik/traefik#4099
  • ❌ Implemented, not merged
• RFC7239 Forwarded Header vulcand/oxy#173
  • ❌ Not implemented
• HAProxy
  • ❌ Not implemented, no issue
• Added new Forwarded header support for Request::getClientIps symfony/symfony#11379
  • ✅ Merged

[francislavoie]

There's a couple go libs that do the parsing:

• https://github.com/theckman/httpforwarded
• https://github.com/stanvit/go-forwarded

They're both over 4 years old though.

[mholt]

Now this is an excellent feature request. 👍 Not because it's a high priority, but because it's well-researched!

[francislavoie]

I don't think there's any plans to implement this at the moment, so I'll mark this "deferred" and close it for now. If there becomes a compelling reason to implement it later (like more of the server applications ecosystem start using it) then we can reopen it. Thanks @0az for the research on the topic!

[Tronic]

It works with Nginx but while looking to switch to Caddy I found no way to implement it. My Sanic services make use of it. There are clear benefits but "no one uses it" remains a chicken-egg problem that can only be fixed by more server implementing it as an option. The de-facto standards are messy in what gets included, whether the original or local "host" header is sent as is, and with some using x-real-ip while others use x-forwarded-for and some append to x-forwarded-for and set x-real-ip with the most recent client IP.

I couldn't even find a custom header definition to do this in Caddy. Is that possible somehow? Ideally such that existing proxy headers are kept but don't need to be converted.

I always use the "secret" parameter suggested in Nginx docs, which prevents spoofing of proxy headers, even when the full chain of proxies are kept. https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

Parsing the header is best done last-to-first header (if there is more than one), right-to-left, such that any injections attempted by client cannot mess up the later records added by trusted proxies. The only difficulty being that values may be quoted, and within quotes , does not separate records, and thus an unclosed quote would mess up the parsing of the rest. Doing it in reverse all the valid records can be read, stopping the parsing at a syntax error and ignoring that record and anything to its left side.

[mholt]

Now that we're about 3 years into Caddy v2, and things are settling down a little, I'd be open to reviewing a PR to implement this. (Just don't have high hopes of it being a one-and-done dealio)