> The code calling request.URLPath(), in a given Resource, or application, is highly unlikely to know whether it wants to honor (x-)forwarded-for.

You are right, I haven't thought about it.

But I'm in doubt whether trusting X-Forwarded-* by default can damage security if Twisted app is running with naked HTTP(S) port exposed without reverse proxy that handles these headers.

There are three headers:

1. X-Forwarded-For specifying original client IP and IPs of proxies

2. X-Forwarded-Host specifying original Host header from the client

3. X-Forwarded-Proto specifying original client's scheme

(there is also new-style "Forwarded:" header but it is not widely used yet, AFAIK)

X-Forwarded-For definetly can't be trusted if comes from untrusted client client. Fortunately we don't need it at all for generating URLs :) It will be in question when refactoring getClientIP() somewhen later.

But can we trust X-Forwarded-Host & X-Forwarded-Proto? From the first glance it isn't a problem since we are using them to display URLs for the same client, so nasty client will get his nasty URLs, that's it. But if app is doing something like storing URL in DB or (more likely) sending an email with a link to another client, this would be an issue.