This thread is mostly about X-Forwarded-Host & X-Forwarded-Proto because the original issue was inability of Twisted Web server to obtain it's public hostname. X-Forwarded-For is another (and probably more complex) story.
Note that the Forwarded header that Tom proposed actually has support for all 4 of these sub-headers:
Just as a point of standards compliance, I'd really like to see support for the standard Forwarded: and non-standard X-Forwarded-...: variants at the same time, since these are just different syntaxes for the same thing.
(Worth noting, I think, that while 'forwarded for' can be spoofed by the client, any client that can set 'forwarded host' can also just set 'host', so there's no security issue here.)
Django indeed dropped support for X-Forwarded-For, but it does support X-Forwarded-Host [1] and X-Forwarded-Proto [2] on opt-in basis.
I'm agree that none of the headers should be trusted by default and that opting-in should be done at Site level.
Great, glad to here we're in agreement there.