> On Mar 15, 2017, at 1:20 AM, Ilya Skriblovsky <ilyaskriblov...@gmail.com> > wrote: > > Ok, so in the sort term you are suggesting to change Request.URLPath
Yes. > (uppercased method? Hmm) Like I said, not a great interface, overall :-). > to use Host header instead of getRequestHostname and to change Klein to use > it instead of Request.getHost(), right? > Sounds wise and reasonable :) OK, glad you agree :). > But I'd like to add one more thing. In order to build correct external URL we > need to know is it http or https. Currently URLPath is using > Request.isSecure(), but it is not sufficient since Request.isSecure() just > checks if backend connection is SSL while encryption is often terminated at a > reverse proxy. Can we add "useXForwardedProto=False" argument to > Request.URLPath() and check X-Forwarded-Proto header if it is true? And may > be add "useXForwardedHost=False" too to simplify setting up a reverse proxy > (with a bold red warning in docstring that it can be set to True only if > reverse proxy is correctly configured to drop corresponding client-specified > headers). What do you think? I think that for starters, it would make more sense to just fix it to always honor forwarded-for and x-forwarded-for headers. The code calling request.URLPath(), in a given Resource, or application, is highly unlikely to know whether it wants to honor (x-)forwarded-for. The code that might know about this sort of configuration would be the thing that constructs the Site object, but I'd be much happier to just get a change that always honors it first, and then figure out how to customize it later. -glyph
_______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
