Hi Joshua How to go with working this out?
Sorry for the delayed reply, but a few comments below. > On 10 Sep 2015, at 12:49 am, Joshua Glenn <[email protected]> wrote: > > Using mod_wsgi-express for the first time. I intend to use this as a solution > to the problem of having two django apps running on different versions of > python (from their respective virtualenvs) on the same box. After a little > trial and error I have successfully started the server. But I have a conf > file for one of my applications that specifies several directives that don't > seem to be covered in the documentation on mod_wsgi-express. I'm not sure how > to direct mod_wsgi-express to respect those directives. > > For instance, in my conf file, apache is directed not to cache my appcache > manifest. Under mod_wsgi-express there is no content caching configured at all by default, so you shouldn’t have an issue with the appcache manifest being cached when it shouldn’t. > Also there are a couple of URL rewrites, etc. (see attached snippet of conf > file) Because of how mod_wsgi-express handles static files inside of htdocs, there may be a better way of handling those rewrites if I understand properly what they are doing. See below. > I tried just using: > > ./db/manage.py runmodwsgi --document-root ./htdocs > > Which loaded up the site that uses Python 3.4 without breaking my other site > which uses Python 2.7. But it loads at a snails pace. To the point that the > loading of one of my js files times out. I'm almost there. I suspect it has > something to do with the directives in the VirtualHost configuration not > being set up properly. Not sure about why it would be slow. Did you work that one out? > How is the best way to go about replicating the setup below using > mod_wsgi-express? > > <VirtualHost *:8000> > ServerName example.com > ServerAlias cp.example.com > DocumentRoot /var/www/cp.example.com/htdocs/ > > <Directory /var/www/cp.example.com/htdocs/> > AllowOverride all > Options FollowSymLinks Multiviews > Order allow,deny > Allow from all > </Directory> > > <Directory /var/www/cp.example.com/media/> > AllowOverride all > Options FollowSymLinks Multiviews > Order allow,deny > Allow from all > </Directory> > > Alias /static /var/www/cp.example.com/htdocs/static > Alias /css /var/www/cp.example.com/htdocs/css > Alias /js /var/www/cp.example.com/htdocs/js > Alias /images /var/www/cp.example.com/htdocs/images > Alias /media /var/www/cp.example.com/media/ > Alias /species.appcache /var/www/cp.example.com/htdocs/species.appcache > Alias /favicon.ico /var/www/cp.example.com/htdocs/favicon.ico > Alias /robots.txt /var/www/cp.example.com/htdocs/robots.txt > <http://cp.example.com/htdocs/robots.txt> All static file assets would simply be placed in the appropriate location under the ‘htdocs’ directory supplied to ‘—document-root’ of mod_wsgi-express. Their location under ‘htdocs’ should match what the sub URL is that they should be available. The way mod_wsgi-express is configured, if it finds a static file at a location matching the URL, then the static file will be served up. If it doesn’t find a static file, then the URL only then falls through to the WSGI application. > # Uncomment the following line to use a static front page > # AliasMatch ^/$ /var/www/cp.example.com/htdocs/index.html > > RewriteEngine On > RewriteCond /var/www/cp.example.com%{REQUEST_FILENAME} !-f > RewriteCond /var/www/cp.example.com/media/$2 -f > RewriteRule ^/media/([^\/]+)/(.+) /generate/$1/$2 [PT] Because of how static files are first checked for and only then request sent through to the WSGI application, instead of these rewrite rules, what you would do is have the WSGI application provide a handler at the exact same sub URL as what the static file being requested would be at. Thus no rewriting to a different sub URL is required as is being done. So when /media/a/b is requested the first time, there will not be a static file for it under ‘htdocs’. Thus the request goes through to the WSGI application with the target URL. The handler for ‘/media/?/?’ would be triggered. That handler could then generate the file contents into a temporary file and when complete, move that file into the correct location under ‘htdocs’ and then return the generated content for that first time from the WSGI application itself. The next time that URL is requested, it will pick up the static file version under htdocs. Technically the WSGI application could possibly avoid even having to serve up the content itself the first time by instead returning an empty 200 response and a ‘Location’ response header with the original URL path. This should actually result in Apache then serving up the now generated static file. The only problem with using that trick though is that only works for mod_wsgi daemon mode, which mod_wsgi-express does use, however, if you ever use debug mode of mod_wsgi-express then than forces Apache into a single process mode using embedded mode and the 200/Location redirect doesn’t work in that case. If wanted one could detect debug mode though and in that case serve up the static file content yourself if it was important. > # WSGIDaemonProcess species display-name=%{GROUP} > python-path=/var/www/cp.example.com/db:/home/ubuntu/.virtualenvs/cpdata/lib/python3.4/site-packages > # WSGIProcessGroup species > # WSGIApplicationGroup %{GLOBAL} > # WSGIScriptAlias / /var/www/cp.example.com/db/species/wsgi.py > > > <Directory /var/www/cp.example.com/db/species> > <Files wsgi.py> > Order allow,deny > Allow from all > </Files> > </Directory> > > AddType text/cache-manifest .manifest > > # Don't cache the appcache! > ExpiresActive on > ExpiresByType text/cache-manifest "access plus 0 seconds" > > > </VirtualHost> > No caching on by default, but using the ‘—include-file’ option you could provide a config file snippet to provide extra directives to enable it and qualify what files shouldn’t be cached. Adding some sort of options to mod_wsgi-express for caching is on the mental TODO list, but use of Apache to do caching can get complicated as you need to specify where they are cached. So right now left to the user using ‘—include-file’. Graham -- 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.
