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 Ben Stähli)

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 Ben Stähli, 5 years ago

Description: modified (diff)

comment:2 by Claude Paroz, 5 years ago

Summary: Forwarded HeaderAdd support for the RFC 7239 Forwarded header

Can you tell us a bit more about the current adoption state of this header?

comment:3 by Ben Stähli, 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.

comment:4 by Carlton Gibson, 5 years ago

Component: UncategorizedHTTP handling
Triage Stage: UnreviewedSomeday/Maybe
Type: UncategorizedNew 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.)

comment:5 by Santiago Basulto, 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)?

Version 0, edited 5 years ago by Santiago Basulto (next)

in reply to:  5 comment:6 by Ben Stähli, 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:

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?

Last edited 5 years ago by Ben Stähli (previous) (diff)

comment:7 by Narbonne, 5 years ago

Cc: Narbonne added

comment:8 by Adam Johnson, 4 years ago

Cc: Adam Johnson added

comment:9 by Maciej Olko, 22 months ago

Cc: Maciej Olko added

comment:10 by braiam, 19 months ago

Cc: braiam added

comment:11 by Ülgen Sarıkavak, 8 months ago

Cc: Ülgen Sarıkavak added

comment:12 by Ryan Hiebert, 8 months ago

Cc: Ryan Hiebert added
Note: See TracTickets for help on using tickets.
Back to Top