One question. Is:
SSLCertificateFile /etc/ssl/certs/***
SSLCertificateKeyFile /etc/ssl/private/**
SSLCertificateChainFile /etc/ssl/certs/**
SSLCipherSuite HIGH:!aNULL:!MD5
what you actually have in the Apache configuration, including the '**', or did
you do that to mask information.
SSL configurations I have seen don't tend to have SSLCertificateChainFile
either. Not sure if that is a requirement for you or not.
Generally I just use:
SLCertificateFile server.crt
SSLCertificateKeyFile server.key
I am always using self signed certificate files though.
Anyway, if you are happy with trying radical solutions, or at least validating
Apache/mod_wsgi with SSL works with a configuration done by someone else, I
have this dead horse called 'pip' I have been trying to sell with not much luck.
Seriously, for a perhaps quick way of testing an alternate SSL configuration
with Apache, try this:
pip install mod_wsgi
sudo mod_wsgi-express start-server --user mod_wsgi --group mod_wsgi --port 80
--ssl-port 443 \
--ssl-certificate server --https-only --server-name redacted --home
/var/www/transfergateway \
--url-alias /media /var/www/transfergateway/myproject/myapp/media \
--url-alias /static /var/www/transfergateway/myproject/myapp/static \
/var/www/transfergateway/myproject/apache/wsgi.py
You would need to stop the existing Apache first. Change 'redacted' to the
actual ServerName value. The user and group to actual names for them. And have
the SSL server.cert and server.key files together in the same directory and
change 'server' argument to --ssl-certificate to be path to directory they are
in, with the common base name part of the files on the end. That is, with
extensions dropped off.
Okay, maybe too radical, but believe it or not that command line should
hopefully run up Apache/mod_wsgi against your Django site if I got all the
arguments right, with HTTPS all setup and in a HTTPS only configuration such
that access to HTTP will redirect automatically to HTTPS URLs.
Worth a try I guess if you really get stuck. :-)
Graham
On 17/12/2014, at 3:18 PM, Jennifer Mehl <[email protected]> wrote:
> Jason,
>
> Having complete example configs would be fantastic. Turning on SSL in Apache
> is what is currently making parts of the app 'break' in IE and Safari. It
> would be great if I could rule out the application code - changing front end
> web servers is probably the only way to do that.
>
> Thanks in advance for the help!
>
> Jennifer
>
>
>> On Dec 16, 2014, at 8:14 PM, Jason Garber <[email protected]> wrote:
>>
>> Hi Jennifer,
>>
>> May I suggest you simplify your apache config by running apache on
>> 127.0.0.1:8086 (for example) and placing nginx in front of it proxying
>> requests to apache. Use nginx for ssl termination.
>>
>> It is dead simple and uncomplicates the apache config.
>>
>> I can provide complete example configs if you wish.
>>
>> Thanks!
>> Jason
>>
>> On Dec 16, 2014 8:03 PM, "Jennifer Mehl" <[email protected]> wrote:
>> Thank you. Good to get those things all cleaned up.
>>
>> I also compiled and installed v4.4.1 of mod_wsgi from source and removed the
>> 3.4 Ubuntu version from my system.
>>
>> Setting DEBUG = False seems to break my application - I get a “Bad Request
>> 400” error back in my browser - so I will check in with the developer on
>> that one.
>>
>> I’ve removed the extraneous environment variables and also the SSL proxy
>> setting. I am only using mod_wsgi with Apache, so, as you say, it shouldn’t
>> need that anyhow.
>>
>> I’ve done the test for the /wsgicheck and it does return a value of https.
>> Thanks for helping me verify that functionality.
>>
>> So, this leaves me with looking at Apache as a culprit - or again, the
>> Django code itself. It’s very odd how only the two browsers are showing
>> issues and they are completely different issues…
>>
>> thanks,
>> Jennifer
>>
>>
>>
>>> On Dec 16, 2014, at 4:41 PM, Graham Dumpleton <[email protected]>
>>> wrote:
>>>
>>> Hmmm, this looks really dangerous:
>>>
>>> DEBUG = "FALSE"
>>>
>>> The DEBUG setting is meant to be a boolean value, not a string.
>>>
>>> Because you are setting it to a non empty string, it will be interpreted as
>>> True and so you have debug mode enabled.
>>>
>>> That is not good as sensitive information could be exposed back to users in
>>> error pages shown in the browser.
>>>
>>> Running in debug mode might cause other issues as well.
>>>
>>> Ensure you are setting it to:
>>>
>>> DEBUG = False
>>>
>>> Also, setting:
>>>
>>> os.environ['HTTPS'] = "on"
>>> os.environ['wsgi.url_scheme'] = 'https'
>>>
>>> will not do anything.
>>>
>>> The wsgi.url_scheme is an attribute which is passed down by mod_wsgi in the
>>> details for each request. A web framework will use the flag from the
>>> request details. The main thing it controls is merely the construction of
>>> absolute URLs when needing to be added to response headers or maybe
>>> response content in some cases.
>>>
>>> In other words, you do not need to set it and setting it in environment
>>> variables wouldn't do anything anyway.
>>>
>>> Next, setting:
>>>
>>> os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
>>>
>>> is okay if you have just the one Django site, but be careful in using this
>>> if you are running more than one. Safer to use:
>>>
>>> os.environ["DJANGO_SETTINGS_MODULE"] = "myproject.settings"
>>>
>>> More details in:
>>>
>>> http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html
>>>
>>> You also don't need:
>>>
>>> SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
>>>
>>> if Apache is your front facing web server. You would only need this if you
>>> had a further front end proxy such as nginx in front of Apache and nginx
>>> had been configured to actually introduce these headers. That your Apache
>>> is accepting HTTPS requests would indicate that you don't have an nginx in
>>> front.
>>>
>>> Now as to determine whether wsgi.url_scheme is set properly, the easiest
>>> way is to take a copy of:
>>>
>>> def application(environ, start_response):
>>> status = '200 OK'
>>> output = str(environ.get('wsgi.url_scheme'))
>>>
>>> response_headers = [('Content-type', 'text/plain'),
>>> ('Content-Length', str(len(output)))]
>>> start_response(status, response_headers)
>>>
>>> return [output]
>>>
>>> Put it in a file called check.py nest to your existing wsgi.py file.
>>>
>>> In the Apache configuration, BEFORE THE LINE:
>>>
>>> WSGIScriptAlias / /var/www/transfergateway/myproject/apache/wsgi.py
>>>
>>> add:
>>>
>>> WSGIScriptAlias /wsgicheck
>>> /var/www/transfergateway/myproject/apache/check.py
>>>
>>> Then down further where have:
>>>
>>> <Directory /var/www/transfergateway/myproject/apache>
>>> <Files wsgi.py>
>>> Order deny,allow
>>> Allow from all
>>> </Files>
>>> </Directory>
>>>
>>> Change it to:
>>>
>>> <Directory /var/www/transfergateway/myproject/apache>
>>> <Files wsgi.py>
>>> Order deny,allow
>>> Allow from all
>>> </Files>
>>> <Files check.py>
>>> Order deny,allow
>>> Allow from all
>>> </Files>
>>> </Directory>
>>>
>>> Restart Apache and then hit the URL of the site for /wsgicheck
>>>
>>> You should see 'https' returned in the page.
>>>
>>> Hope this helps.
>>>
>>> Graham
>>>
>>> On 17/12/2014, at 11:09 AM, Jennifer Mehl <[email protected]> wrote:
>>>
>>>> No problem, if I have to compile from source, then I will try that.
>>>>
>>>> One last thing regarding HTTPS - how do I ensure that I have the
>>>> wsgi.url_scheme set correctly?
>>>>
>>>> Here is my wsgi.py file:
>>>>
>>>> import os
>>>> import sys
>>>>
>>>> path='/var/www/transfergateway/myproject'
>>>>
>>>> #if path not in sys.path:
>>>> #sys.path.append(path)
>>>>
>>>> os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
>>>>
>>>> #HTTPS
>>>> os.environ['HTTPS'] = "on"
>>>>
>>>> # This application object is used by any WSGI server configured to use this
>>>> # file. This includes Django's development server, if the WSGI_APPLICATION
>>>> # setting points here.
>>>> from django.core.wsgi import get_wsgi_application
>>>> application = get_wsgi_application()
>>>>
>>>>
>>>>
>>>>
>>>> and here is relevant stuff from my settings.py file:
>>>>
>>>> import os
>>>> PROJECT_ROOT = os.path.realpath(os.path.dirname(__file__))
>>>>
>>>>
>>>> #turn off debug when going to production
>>>> DEBUG = "FALSE"
>>>> TEMPLATE_DEBUG = DEBUG
>>>>
>>>>
>>>> # Python dotted path to the WSGI application used by Django's runserver.
>>>> WSGI_APPLICATION = 'myproject.wsgi.application'
>>>>
>>>>
>>>> #session expire at browser close
>>>> SESSION_EXPIRE_AT_BROWSER_CLOSE = True
>>>> SESSION_COOKIE_HTTPONLY=True
>>>>
>>>> #idle timeout
>>>> SESSION_IDLE_TIMEOUT=900
>>>>
>>>> #HTTPS stuff - secure proxy SSL header - do I need this?
>>>> SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
>>>> #HTTPS stuff - secure cookies
>>>> SESSION_COOKIE_SECURE = True
>>>> CSRF_COOKIE_SECURE = True
>>>>
>>>> #HTTPS WSGI
>>>> os.environ['wsgi.url_scheme'] = 'https'
>>>>
>>>>
>>>>
>>>>> On Dec 16, 2014, at 3:59 PM, Graham Dumpleton
>>>>> <[email protected]> wrote:
>>>>>
>>>>> You will unfortunately not find a binary OS supplied Ubuntu 10.4 package
>>>>> for mod_wsgi which is newer.
>>>>>
>>>>> Your only choice would be to compile from source code.
>>>>>
>>>>> Graham
>>>>>
>>>>> On 17/12/2014, at 10:54 AM, Jennifer Mehl <[email protected]> wrote:
>>>>>
>>>>>> Thanks for this info. I’ll try a newer mod_wsgi.
>>>>>>
>>>>>> It’s very odd to me that the app works fine in mod_wsgi/Apache with no
>>>>>> SSL but parts become broken in certain browsers once SSL is enabled.
>>>>>>
>>>>>> At any rate, thanks for the guidance and I’ll report back if I find a
>>>>>> fix!
>>>>>>
>>>>>> —Jennifer
>>>>>>
>>>>>>> On Dec 16, 2014, at 3:46 PM, Graham Dumpleton
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>> If you are using mod_wsgi 3.4 that could be a problem in itself.
>>>>>>>
>>>>>>> Recent versions of Ubuntu as I understand it use Apache 2.4, but such
>>>>>>> an old version of mod_wsgi may have issues on Apache 2.4. At the
>>>>>>> minimum would need to have mod_wsgi 3.5 from memory as some Apache 2.4
>>>>>>> fixes were back ported to 3.5. It is unlikely they back ported those
>>>>>>> themselves to 3.4 for 14.04.
>>>>>>>
>>>>>>> Either way, mod_wsgi itself shouldn't be causing any problems with
>>>>>>> HTTPS as it is Apache that deals with all that and mod_wsgi has nothing
>>>>>>> to do with the handling of secure connections. When mod_wsgi sees a
>>>>>>> request that came via HTTPS it sees it as being no different to a HTTP
>>>>>>> request with the exception of what the wsgi.url_scheme attribute is set
>>>>>>> to. It is therefore more likely to be an Apache configuration issue or
>>>>>>> issue with the code of Apache itself.
>>>>>>>
>>>>>>> FWIW, mod_wsgi 3.4 means that Ubuntu version is almost 20 versions
>>>>>>> behind. Even Ubuntu 14.10 has only mod_wsgi 3.5. It is quite
>>>>>>> frustrating that they haven't been bothered to update their packages to
>>>>>>> more recent versions even if only for the most recent 14.10.
>>>>>>>
>>>>>>> About the only thing I can suggest if it is readily reproducible, is to
>>>>>>> use request logging such as described in:
>>>>>>>
>>>>>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response
>>>>>>>
>>>>>>> to see if when a request has issues, that the WSGI application actually
>>>>>>> returned the requests properly.
>>>>>>>
>>>>>>> If it isn't, then use something like:
>>>>>>>
>>>>>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Extracting_Python_Stack_Traces
>>>>>>>
>>>>>>> to get out Python stack traces for where a request handler may be stuck.
>>>>>>>
>>>>>>> Both can be fiddly so sounds like you aren't going to have time to do
>>>>>>> that.
>>>>>>>
>>>>>>> Graham
>>>>>>>
>>>>>>> On 17/12/2014, at 10:04 AM, Jennifer Mehl <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I’m on the latest for Ubuntu 14.04LTS - 2.4.7-1ubuntu4.1. I have been
>>>>>>>> using the updated mod_wsgi3.4 from Ubuntu.
>>>>>>>>
>>>>>>>> At this point I was thinking about trying my Django application in a
>>>>>>>> different WSGI server to see if I can narrow down if the problem is
>>>>>>>> with the Django code or something with mod_wsgi. I was thinking about
>>>>>>>> uwsgi (trying to find something quick and easy to test) or nginx.
>>>>>>>>
>>>>>>>> Again, the weird browser behavior I describe below only happens when
>>>>>>>> using Apache/HTTPS, port 443, in mod_wsgi (not Apache/HTTP in mod_wsgi
>>>>>>>> or the Django development server in port 80).
>>>>>>>>
>>>>>>>> I’m kind of at my wit’s end trying to narrow down *where* the problem
>>>>>>>> is (if it’s something in the Django code, I only have one more day
>>>>>>>> until my developer leaves for a few weeks for winter break…) Do you
>>>>>>>> think there any debugging I can do by looking at the developer console
>>>>>>>> in the affected browsers - for instance comparing the affected pages
>>>>>>>> on a working port 80 vs the same pages on the non-working SSL/port 443
>>>>>>>> connection?
>>>>>>>>
>>>>>>>> thank you,
>>>>>>>> Jennifer
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Dec 16, 2014, at 2:55 PM, Graham Dumpleton
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>> One more question. What version of Apache are you using?
>>>>>>>>>
>>>>>>>>> If you are stuck on a quite old Apache 2.2.X version that would be a
>>>>>>>>> concern as there were various SSL related issues patched during the
>>>>>>>>> life of Apache 2.2.X.
>>>>>>>>>
>>>>>>>>> Graham
>>>>>>>>>
>>>>>>>>> On 16/12/2014, at 11:40 AM, Graham Dumpleton
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> I'll go through the description you gave me and see if can suggest
>>>>>>>>>> anything, but first up, what version of mod_wsgi are you using?
>>>>>>>>>>
>>>>>>>>>> If you are using mod_wsgi 4.4.0 make sure you update to 4.4.1. The
>>>>>>>>>> newer version resolves a potential for process crashing introduced
>>>>>>>>>> in 4.4.0.
>>>>>>>>>>
>>>>>>>>>> Graham
>>>>>>>>>>
>>>>>>>>>> On 16/12/2014, at 11:33 AM, Jennifer Mehl <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi there,
>>>>>>>>>>>
>>>>>>>>>>> I am backpedalling a bit from my previous attempt to chroot
>>>>>>>>>>> mod_wsgi - instead, for now, just to get this Django application
>>>>>>>>>>> running, for simplicity, I am going to start out with just running
>>>>>>>>>>> it as a daemon as a restricted user.
>>>>>>>>>>>
>>>>>>>>>>> In doing the final testing of my application on various browsers, I
>>>>>>>>>>> have noticed some strange problems.
>>>>>>>>>>>
>>>>>>>>>>> When I run Django/mod_wsgi/Apache on port 80 (same config as below,
>>>>>>>>>>> minus the mod_ssl stuff) or use the django development runserver
>>>>>>>>>>> 0.0.0.0:80, and disable the following settings in settings.py
>>>>>>>>>>> (#SESSION_COOKIE_SECURE = True #CSRF_COOKIE_SECURE = True) these
>>>>>>>>>>> browsers work correctly in the app.
>>>>>>>>>>>
>>>>>>>>>>> However, when running Django application running through mod_wsgi
>>>>>>>>>>> and HTTPS/port 443 in Apache, I see problems with both IE and
>>>>>>>>>>> Safari browsers. After login on Internet Explorer, page timeouts
>>>>>>>>>>> occur in various locations, reporting "This page can't be
>>>>>>>>>>> displayed". On Safari, the app won't get past the secondary Duo
>>>>>>>>>>> MFA authentication step, saying "Server unexpectedly dropped the
>>>>>>>>>>> connection." It is not a consistent behavior - seems to happen more
>>>>>>>>>>> frequently if I click quickly through links. Sometimes if I wait
>>>>>>>>>>> long enough to click, it might work momentarily, but then not again
>>>>>>>>>>> a moment later. This behavior does NOT happen using Chrome or
>>>>>>>>>>> Firefox browsers on any OS.
>>>>>>>>>>>
>>>>>>>>>>> Apache config:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <IfModule mod_ssl.c>
>>>>>>>>>>>
>>>>>>>>>>> <VirtualHost *:443>
>>>>>>>>>>>
>>>>>>>>>>> ServerName **redacted**
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> #Django WSGI - Daemon
>>>>>>>>>>>
>>>>>>>>>>> WSGIScriptAlias / /var/www/transfergateway/myproject/apache/wsgi.py
>>>>>>>>>>>
>>>>>>>>>>> WSGIProcessGroup file-xfer
>>>>>>>>>>>
>>>>>>>>>>> WSGIDaemonProcess file-xfer user=mod_wsgi group=mod_wsgi
>>>>>>>>>>> processes=2 threads=25 python-path=/var/www/transfergateway
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <Directory /var/www/transfergateway/myproject/apache>
>>>>>>>>>>>
>>>>>>>>>>> <Files wsgi.py>
>>>>>>>>>>>
>>>>>>>>>>> Order deny,allow
>>>>>>>>>>>
>>>>>>>>>>> Allow from all
>>>>>>>>>>>
>>>>>>>>>>> </Files>
>>>>>>>>>>>
>>>>>>>>>>> </Directory>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Alias /robots.txt
>>>>>>>>>>> /var/www/transfergateway/myproject/myapp/static/robots.txt
>>>>>>>>>>>
>>>>>>>>>>> Alias /favicon.ico
>>>>>>>>>>> /var/www/transfergateway/myproject/myapp/static/favicon.ico
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> AliasMatch ^/([^/]*\.css)
>>>>>>>>>>> /var/www/transfergateway/myproject/myapp/static/styles/$1
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Alias /media/ /var/www/transfergateway/myproject/myapp/media/
>>>>>>>>>>>
>>>>>>>>>>> Alias /static/ /var/www/transfergateway/myproject/myapp/static/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <Directory /var/www/transfergateway/myproject/myapp/static>
>>>>>>>>>>>
>>>>>>>>>>> Order deny,allow
>>>>>>>>>>>
>>>>>>>>>>> Allow from all
>>>>>>>>>>>
>>>>>>>>>>> </Directory>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <Directory /var/www/transfergateway/myproject/myapp/media>
>>>>>>>>>>>
>>>>>>>>>>> Order deny,allow
>>>>>>>>>>>
>>>>>>>>>>> Allow from all
>>>>>>>>>>>
>>>>>>>>>>> </Directory>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ErrorLog ${APACHE_LOG_DIR}/error.log
>>>>>>>>>>>
>>>>>>>>>>> CustomLog ${APACHE_LOG_DIR}/access.log combined
>>>>>>>>>>>
>>>>>>>>>>> SSLEngine on
>>>>>>>>>>>
>>>>>>>>>>> SSLCertificateFile /etc/ssl/certs/***
>>>>>>>>>>>
>>>>>>>>>>> SSLCertificateKeyFile /etc/ssl/private/**
>>>>>>>>>>>
>>>>>>>>>>> SSLCertificateChainFile /etc/ssl/certs/**
>>>>>>>>>>>
>>>>>>>>>>> SSLCipherSuite HIGH:!aNULL:!MD5
>>>>>>>>>>>
>>>>>>>>>>> </VirtualHost>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> </IfModule>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, I'm concluding that the HTTPS problem is one of two things: how
>>>>>>>>>>> I am configuring mod_wsgi with HTTPS, or some issue inside the
>>>>>>>>>>> Django code (but HTTPS works on some browsers with no issues, so
>>>>>>>>>>> I'm stumped...)
>>>>>>>>>>>
>>>>>>>>>>> Is there anything special that I need to do in mod_wsgi or the
>>>>>>>>>>> Django application itself, in order to make the application HTTPS
>>>>>>>>>>> only? (I am not a Python or Django developer, so I would be
>>>>>>>>>>> passing info on to the actual application developer for
>>>>>>>>>>> resolution.) Any ideas?
>>>>>>>>>>>
>>>>>>>>>>> thank you,
>>>>>>>>>>> Jennifer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>>>> Groups "modwsgi" group.
>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>>> send an email to [email protected].
>>>>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>>>> the Google Groups "modwsgi" group.
>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>>>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>>>> [email protected].
>>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "modwsgi" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>>>> an email to [email protected].
>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to a topic in the
>>>>>>> Google Groups "modwsgi" group.
>>>>>>> To unsubscribe from this topic, visit
>>>>>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>> [email protected].
>>>>>>> To post to this group, send email to [email protected].
>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "modwsgi" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an email to [email protected].
>>>>>> To post to this group, send email to [email protected].
>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "modwsgi" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "modwsgi" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at http://groups.google.com/group/modwsgi.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "modwsgi" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/modwsgi.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "modwsgi" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/modwsgi.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
