Fantastic - thanks again! Jennifer
> On Dec 16, 2014, at 9:14 PM, Jason Garber <[email protected]> wrote: > > I will send in the morning (eastern). > > On Dec 16, 2014 11: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 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.
