On 10/30/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote: ... > In mod_wsgi, although the application entry point is defined twice, > mod_wsgi will recognise that they are on 80/443 for the same site and > ensure that only one Django instance runs in each Apache process, but > with both HTTP and HTTPS requests going to it. Whether the original > request was HTTP or HTTPS will be obtained from the is_secure() > function within Django API.
I'm sorry to spread FUD here, but when running two interpreters (one for SSL, one for HTTP) for the same django settings file, is_secure has not consistently given the right answer. A while back, we tried to fix this by shifting to mod_python's req.is_https, but it was backed out, since that was just introduced with 3.2.10. You can read up on is_https's implementation to see why it was done, but I suspect Django's approach is flawed. (Graham, I'm sure you know this area better than me.) This is the current logic: return 'HTTPS' in self._req.subprocess_env and self._req.subprocess_env['HTTPS'] == 'on' >From what I saw, the subprocess_env sometimes didn't have 'HTTPS' == 'on', even when serving an HTTPS request. I asked people from 2 other Django sites under both HTTP and HTTPS-- they each happen to run separate apache instances for HTTP and HTTPS rather than using vhost under a single instance. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
