Whoops. Should have been --working-directory instead of --home. Graham
On 18/12/2014, at 6:35 AM, Jennifer Mehl <[email protected]> wrote: > 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. -- 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.
