I gave this mod_wsgi-express a try, but it is spitting out an error about the —home option not being a valid option. What should I be using instead?
thanks, Jennifer > On Dec 16, 2014, at 9:32 PM, Graham Dumpleton <[email protected]> > wrote: > > 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�0 >>>>> >>>>> #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% 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 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.
