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.
