https_fixup.py

[Jim Hague]

Hi all,

This rambles a bit, but basically turns into a question for the deployment and 
WSGI-knowledgeable.

I wasted a bit of time Friday night working out why 'force_https' wasn't 
working. Dolt that I am, there is a pull request fixing the problem. By the 
time Mads pointed me at it, I'd submitted a pull request of my own with the 
fix plus an update to the docs adding info on the 'https_fixups' config.

Mads has commented on that:
> I consider force_https and the other https_fixups for hacks that are needed
> because of deficiencies in paster (or somewhere else in the stack we use).
> WSGI web servers should set wsgi.url_scheme correctly. If the setup has
> proxies that change protocols, hostnames, ports or paths, then the web
> server (or in worst case: middleware) should make sure the WSGI environment
> looks like it didn't. I am thus reluctant to advertise the workarounds we
> have in Kallithea. We should make it simple to do it the right way.

This is not something I know much/anything about. But I've done some 
investigation this morning. To recap, https_fixup.py offers 3 configs:

1. force_https. Always use HTTPS as the protocol for redirects.
2. https_fixups. Check for headers X-Url-Scheme, X-Forwarded-Scheme or
   X-Forwarded-Proto in the request and if found use that protocol.
3. use_htsts. Add header
   'Strict-Transport-Security=max-age=8640000; includeSubDomains'
   to replies, telling compliant clients to use HTTPS for subsequent
   queries. http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security.

(1) and (2) are typically useful when used with reverse proxies. Which is my 
use case.

The default production.ini uses Waitress 0.8.8 as the WSGI server. This can do 
(1) by setting config 'url_scheme=https'.

To do (2) with Waitress requires upgrading to 0.8.9. Traffic from a server 
listed in config 'trusted_proxy' will observe X-Forwarded-Proto.

I've not found a way to do (3) with Waitress.

I take Mads' point. Equally, I think working behind a proxy and requiring 
either (1) or (2) is an important use case. So, as I see it, we should:

a) Fix 'force_https' and document 'https_fixups', or
b) Update to Waitress 0.8.9, change the documentation to specify how to do (1)
   and (2) via Waitress, and remove the relevant Kallithea code, or
c) Update to Waitress 0.8.9, change the documentation to specify how to do (1)
   and (2) via Waitress, and document the Kallithea settings in some
   'Advanced' addendum.

Question: How likely is it that users of another WSGI server will still need 
Kallithea to do (1) and/or (2)?

>From my ignorant PoV, it seems that if Waitress only acquired the ability to 
do (2) in a release made in mid-May this year, the chances are reasonable that 
other WSGI servers will be lacking, and so (a) is the way to go.
-- 
Jim Hague - jim.hague at acm.org          Never trust a computer you can't lift.