Support X-Forwarded-* and Forwarded implicitly, deprecate secure_proxy_ssl_header.

[asvetlov]

It's not obvious and the current doc is misleading: it proposes secure_proxy_ssl_header='X-Forwarded-Proto' but should do secure_proxy_ssl_header=('X-Forwarded-Proto', 'https').

Looks like @popravich made a mistake on documenting it by d4954ef

1. X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto should be supported. See the spec at http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html
2. Forwarded header from RFC 7239 https://tools.ietf.org/html/rfc7239 should be supported as well.

The issue doesn't require a single Pull Request, most likely it should be several PRs, each for other aspect for sake of easy reviewing etc.

Until we'll remove deprecated secure_proxy_ssl_header support it should be processed first before all other rules.

[evertlammerts]

What's the status on this? I'm going to use:

• Forwarded
• X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For
• Host

... to try to determine how & where my service can be reached during runtime. I can do this in my own code but I can also shoot in a PR. How about this approach:

• add the above headers to aiohttp.hdrs
• use them in the above order in Request._scheme, Request.host and Request.url in an attempt to determine the correct vales
• explain resolution order in the docs

Would that be useful enough to be included?

[fafhrd91]

@evertlammerts PR would be very good!

[evertlammerts]

How about something like this? There are no tests in there yet and I'm not sure how deprecation works in aiohttp. Any pointers?

I'll revisit soon, just about to leave on a trip.

[fafhrd91]

we use deprecation warning. but what do you want to deprecate?