<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 20, 2017, at 12:23 PM, Ilya Skriblovsky <<a href="mailto:ilyaskriblovsky@gmail.com" class="">ilyaskriblovsky@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote><div><br class=""></div><div>Note that the Forwarded header that Tom proposed actually has support for all 4 of these sub-headers:</div><div><br class=""></div><div><div class=""><a href="https://tools.ietf.org/html/rfc7239#s" class="">https://tools.ietf.org/html/rfc7239#s</a>ection-5.3</div></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>(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.)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div><div style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I'm agree that none of the headers should be trusted by default and that opting-in should be done at Site level.</div></div></blockquote><br class=""></div><div>Great, glad to here we're in agreement there.</div><div><br class=""></div><div>-glyph</div></body></html>