Re: internal vs. external hostname in Request.getHost9)

Glyph Lefkowitz <[email protected]> Mon, 20 Mar 2017 23:04:08 -0700
Newsgroups gmane.comp.python.twisted.web
Message-ID <[email protected]>
--===============6239047446642741958==
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_1EF8CCA6-C8F6-47BD-96B0-51A013590D8E"


--Apple-Mail=_1EF8CCA6-C8F6-47BD-96B0-51A013590D8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Mar 20, 2017, at 12:23 PM, Ilya Skriblovsky =
<[email protected]> wrote:
>=20
> 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:

https://tools.ietf.org/html/rfc7239#section-5.3

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.
>=20
> 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.

-glyph=

--Apple-Mail=_1EF8CCA6-C8F6-47BD-96B0-51A013590D8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Mar 20, 2017, at 12:23 PM, Ilya Skriblovsky &lt;<a =
href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
style=3D"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=3D"">This thread is mostly =
about X-Forwarded-Host &amp; 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=3D""></div><div>Note that =
the Forwarded header that Tom proposed actually has support for all 4 of =
these sub-headers:</div><div><br class=3D""></div><div><div class=3D""><a =
href=3D"https://tools.ietf.org/html/rfc7239#s" =
class=3D"">https://tools.ietf.org/html/rfc7239#s</a>ection-5.3</div></div>=
<div><br class=3D""></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=3D""></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=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
style=3D"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=3D"">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=3D"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=3D""><br class=3D""></div><div style=3D"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=3D"">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=3D""></div><div>Great, glad to =
here we're in agreement there.</div><div><br =
class=3D""></div><div>-glyph</div></body></html>=

--Apple-Mail=_1EF8CCA6-C8F6-47BD-96B0-51A013590D8E--


--===============6239047446642741958==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web

--===============6239047446642741958==--