#2092 closed defect (fixed)
Wrong redirect to https URL when using django with mod_python
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | normal | Keywords: | |
Cc: | k.shaposhnikov@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently in django/middleware/common.py following code is used to determine whether http or https URL should be used for redirect:
os.environ.get('HTTPS') == 'on'
This doesn't work in all cases at least with mod_python. mod_python doesn't create new process every time it process request, instead it reused already created processes.
Consider following scenario:
- I've requested some URL of my application using HTTPS protocol. mod_python created new process A and sets HTTPS environment variable to 'on'
- I've requested some other URL using HTTP (http://localhost/test), but redirect is required to http://localhost/test/. mod_python processes this request using the same process A, and I will be redirected to URL with HTTPS protocol: https://localhost/test/
I am not mod_python expert, but I've searched mod_python mailing lists and found following thread (by Adrian Holovaty BTW :) :
http://www.modpython.org/pipermail/mod_python/2004-September/016448.html
So the right way is to check https protocol for mod_python is:
req.subprocess_env.has_key('HTTPS') and req.subprocess_env['HTTPS'] == 'on'
As I understand following code in ModPythonHandler exists to solve the problem:
os.environ.update(req.subprocess_env)
Unfortunately it doesn't solve problem with HTTPS, because HTTPS is already 'on' in os.environ and is not presented at all in req.subprocess_env.
Possible solutions:
- explicitly check for HTTPS environment variable
- add is_ssl() method to HttpRequest and use it
(In [3410]) Fixed #2092: added a "is_secure()" method to HttpRequest which correctly handles the subtleties of mod_python's interaction with os.environ. This one's been bugging me for about a *year*, so many many thanks to k.shaposhnikov@… for figuring it out, and Tim Shaffer for pointing out this ticket.