On Oct 31, 10:23 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> 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.
In mod_wsgi you aren't running two interpreters, one for HTTP and one
for HTTPS. It realises that 80/433 are generally always paired and
uses one interpreter to span both ports. It is only when you use a non
80 or 443 port that mod_wsgi will farm it off into a separate
interpreter.
So, for port 80 and port 443, for site.com and Django mounted on root,
the interpreter (application group) name will for mod_wsgi be:
site.com|
If you run something on port 8080, it will be:
site.com:8080|
If running mod_python, it will by default to using one interpreter for
all ports for a virtual host server name. Ie., it would separate 80
and 443, but also wouldn't separate 8080 either. Thus in mod_python,
the interpreter name would just be:
site.com
> 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'
Hmmm, using req.is_https() was put back in trunk, if it fails, because
it didn't exist, it would fallback to looking for HTTPS in
req.subprocess_env.
44 def is_secure(self):
45 try:
46 return self._req.is_https()
47 except AttributeError:
48 # mod_python < 3.2.10 doesn't have req.is_https().
49 return self._req.subprocess_env.get('HTTPS',
'').lower() in ('on', '1')
The changes were:
http://code.djangoproject.com/changeset/6359#file0
Presume you aren't using trunk then.
> From what I saw, the subprocess_env sometimes didn't have 'HTTPS' ==
> 'on', even when serving an HTTPS request.
A problem with Django's WSGI adapter there for a while was that it was
using the mod_python approach to determining if HTTPS which was wrong,
the trunk now has:
107 def is_secure(self):
108 return 'wsgi.url_scheme' in self.environ \
109 and self.environ['wsgi.url_scheme'] == 'https'
which is the correct way. The change was:
http://code.djangoproject.com/changeset/6428#file0
Before it was also only looking for 'on' where as some WSGI servers
would supply '1' for HTTPS if it did set it.
> 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.
I don't understand why unless there are other problems in Django or
how settings.py file is used. At mod_python or mod_wsgi level it
should matter.
Now, whether it will only work properly if using trunk is a different
matter. :-)
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
