Opened 5 years ago
Last modified 8 months ago
#30729 new New feature
Add support for the RFC 7239 Forwarded header
Reported by: | Ben Stähli | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | 2.2 |
Severity: | Normal | Keywords: | |
Cc: | Narbonne, Adam Johnson, Maciej Olko, braiam, Ülgen Sarıkavak, Ryan Hiebert | Triage Stage: | Someday/Maybe |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
As seen here https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded the Forwarded header seems to become the new and standardized way to define the forwarded ip/protocol when using a proxy. And to superseed the existing (well established) X-Forwarded-For/Proto/Protocol/etc headers.
A quick glimpse in into the code looks like currently there is still the "legacy" approach used. Are there any plans to use the new header?
Change History (12)
comment:1 by , 5 years ago
Description: | modified (diff) |
---|
comment:2 by , 5 years ago
Summary: | Forwarded Header → Add support for the RFC 7239 Forwarded header |
---|
comment:3 by , 5 years ago
Not really. But it would be a good thing to go ahead and support it, otherwise it will never be adopted. Also, it is an RFC, so I guess it will probably become the new standard. Tomorrow, or in some years only, who knows.
A quick research shows that some frameworks are discussing it.
- https://duckduckgo.com/?q=is+RFC-7239+forwarded+support&t=canonical&ia=web
- https://github.com/aspnet/AspNetCore/issues/5978
- https://issues.jboss.org/browse/UNDERTOW-1207?_sscc=t
- http://tomcat.10.x6.nabble.com/Bug-63080-New-Support-rfc7239-Forwarded-header-td5081951.html
- https://groups.google.com/forum/#!msg/golang-nuts/wc45kx0bsr8/BX1Dds8cAwAJ
comment:4 by , 5 years ago
Component: | Uncategorized → HTTP handling |
---|---|
Triage Stage: | Unreviewed → Someday/Maybe |
Type: | Uncategorized → New feature |
I'm tempted to say needsinfo
here, but, yes there's the RFC so I guess we should pick it up at some point.
A case insenstive search for x[-_]forwarded
doesn't turn up too many results, so in theory it's easy enough... but we'd need to think about supporting both approaches, probably indefinitely, and provide decent documentation around that, and a migration to the new header from the old (ones).
I'd like to see some detail on all that before we say "Yes, let's go! Accepted". As such we'll call it Someday/Maybe for now. (Happy to see more detail and/or an adjustment if someone wants to push it forward.)
follow-up: 6 comment:5 by , 5 years ago
I'd be tempted to take over this. I'd like to know what would "add support" involves. Is it just trusting hosts based on X-Forwarded as we do with [x-forwarded-host](https://docs.djangoproject.com/en/3.0/ref/settings/#use-x-forwarded-host)?
comment:6 by , 5 years ago
add support means all aspects of the new header need to be covered. as far as I can see, this touches at least these settings/aspects:
- SECURE_PROXY_SSL_HEADER https://docs.djangoproject.com/en/3.0/ref/settings/#secure-proxy-ssl-header
- USE_X_FORWARDED_HOST https://docs.djangoproject.com/en/3.0/ref/settings/#use-x-forwarded-host
- USE_X_FORWARDED_PORT https://docs.djangoproject.com/en/3.0/ref/settings/#use-x-forwarded-port
and, the parsing and security part is not to underestimate, as it's only one header, that must be parsed.
Replying to Santiago Basulto:
I'd be tempted to take over this. I'd like to know what would "add support" involves. Is it just trusting hosts based on X-Forwarded as we do with x-forwarded-host?
comment:7 by , 5 years ago
Cc: | added |
---|
comment:8 by , 4 years ago
Cc: | added |
---|
comment:9 by , 22 months ago
Cc: | added |
---|
comment:10 by , 19 months ago
Cc: | added |
---|
comment:11 by , 8 months ago
Cc: | added |
---|
comment:12 by , 8 months ago
Cc: | added |
---|
Can you tell us a bit more about the current adoption state of this header?