https_fixup.py

[Jim Hague]

On Tuesday 07 Oct 2014 16:46:25 Mads Kiilerich wrote:
> > 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.

> PasteDeploy also seems to be able to do this in PrefixMiddleware.

True. It looks like merely enabling proxy-prefix filter will use X-Forwarded-
Scheme or  X-Forwarded-Proto by default, and you can set 'scheme' to force. So 
we could just modify the docs to use proxy-prefix and avoid needing to update 
Waitress. However, that drags another component into the processing. Perhaps 
it would be better to do it in Waitress.

Looking at other apps, Django and Flask also recognise X-Fowarded-Proto. Among 
the WSGI servers GUnicorn, CherryPy and Tornado do. As far as I can see, uWSGI 
only allows HTTPS to be forced. Those are all I've looked at so far.

In other words, FWIW, X-Forwarded-Proto looks like something close to a de-
facto standard.

I'm guessing the primary motivation behind including X-Forwarded-Proto support 
in the app is to provide universal support in a simply documented form and to 
avoid having to learn the config ins and outs of a hundred random WSGI 
servers.

BTW, the current proxy setup in the docs, which sets environment HTTPS, works 
on Paste but not on Waitress. We should definitely switch that example to X-
Forwarded-Proto.

Looking at the history, it appears Waitress is the default because it works 
properly with git.

> > 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
> 
> That sounds like a good solution. Depending on how stable and widespread
> that version is, we should consider to just also support that version
> and document how to utilize it.

Looks to me like WSGI servers are like web servers, but more so - each is good 
for some loads and not others. I suspect none is notably more widespread than 
others, and picking a winner is not going to happen.

It looks like the Waitress version has been updated frequently in the past. 
Updating to 0.8.9, the current release, is not unreasonable.

> I think it has value to keep the hacks and stay backward compatible. But
> we should not recommend using them.

Yeah, I think we have to keep the hacks.

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

I'm increasingly feeling that this stuff 'should' happen in the WSGI server, 
but we have to be pragmatic too. 
-- 
Jim Hague - jim.hague at acm.org          Never trust a computer you can't lift.