<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 11:30 AM, Tom Most <<a href="mailto:tommost@gmail.com" class="">tommost@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="">If Twisted is to support this in any way, I think that it should be opt-in support for the Forwarded header as specified in RFC 7239. This should be a parameter applicable to all of twisted.web.server rather than per-method call, since it's something the administrator needs to set.<br class=""></div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">I'm generally in agreement with this. Further, we should probably have some notion of authentication, i.e. Site(..., trustForwardedForFrom=[...]), where [...] could be, let's say a twisted.internet.ssl.Certificate representing a client CA to check client connections from, or a list of twisted.internet.address.IPv4Address objects naming servers on a network we can trust. Effectively building in authentication to this layer is important (and since twisted is a web _server_ and not a web framework, more generally possible than e.g. Django).</div><div class=""><br class=""></div><div class="">-glyph</div></body></html>