2 votes

mod_wsgi, .htaccess et rewriterule

J'utilise plusieurs projets django fonctionnant sur la même instance d'apache via mod_wsgi, configurée avec un virtualhost pour chaque site, voir le httpd.conf aquí . Pour l'un des sites, je veux utiliser le cache statique ( Générateur statique ), j'ai donc créé un répertoire avec un fichier .htaccess qui contient :

RequestHeader unset X-Forwarded-Host
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteRule ^(.*) http://127.0.0.1:3456/$1 [P]

où 3456 est le port de django sur le serveur. En utilisant cette règle de réécriture, la requête est toujours transmise au gestionnaire mod_wsgi, même si le fichier ou le répertoire existe, et si le fichier index.html existe la demande montre comme request-path/index.html . J'ai essayé une autre configuration :

RequestHeader unset X-Forwarded-Host
RewriteEngine on
RewriteBase /
RewriteCond $1 !-d
RewriteCond $1index.html !-f
RewriteRule ^(.*) http://127.0.0.1:3456/$1 [P]

mais j'ai obtenu presque les mêmes résultats. Toutes les demandes sont transférées au gestionnaire mod_wsgi, mais le chemin de la demande est maintenant celui d'origine. Pour résumer :

  1. Quel est le RewriteCond correct à utiliser ici ?
  2. Comment transférer une requête au gestionnaire mod_wsgi ? Est-ce la bonne méthode ?
  3. Si ce n'est pas la façon de faire, alors comment servir les fichiers statiques à partir d'un répertoire quand ils existent, et quand ils n'existent pas, les servir à partir de apache/mode_wsgi ?

Merci pour votre aide.

2voto

Jason Points 8799

Sans faire de tests, utilisez quelque chose comme :

<Virtualhost *:28512>

ServerName site1.com
ServerAlias www.site1.com

DocumentRoot /home/mehome/webapps/djangoprojects/site1

<Directory /home/mehome/webapps/djangoprojects/site1>
Order allow,deny
Allow from all
AddHandler wsgi-script .wsgi
Options ExecCGI

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L]
</Directory>

</VirtualHost>

Mettez votre fichier Django WSGI script comme :

/home/mehome/webapps/djangoprojects/site1/site.wsgi

Il doit contenir le fixup tel qu'il est documenté dans le wiki mod_wsgi, de sorte qu'il dise quelque chose du genre :

import django.core.handlers.wsgi
_application = django.core.handlers.wsgi.WSGIHandler()

import posixpath
def application(environ, start_response):
    # Wrapper to set SCRIPT_NAME to actual mount point.
    environ['SCRIPT_NAME'] = posixpath.dirname(environ['SCRIPT_NAME'])
    if environ['SCRIPT_NAME'] == '/':
        environ['SCRIPT_NAME'] = ''
    return _application(environ, start_response)

Ensuite, le générateur de fichiers statiques dépose les fichiers dans l'emplacement approprié en fonction de l'URL sous laquelle il doit correspondre :

/home/mehome/webapps/djangoprojects/site1

La règle de réécriture doit vérifier si Apache a trouvé un fichier statique pour l'URL et, dans le cas contraire, le rediriger vers l'application Django.

Il est préférable de demander ce genre de configuration complexe sur la liste de diffusion officielle mod_wsgi. Cet exemple a été présenté à plusieurs reprises dans le passé et se trouve dans les archives de la liste de diffusion, de même que la base de cet exemple est expliquée dans la documentation.

1voto

Je voulais éviter le Directory aussi, je préfère la directive WSGIScriptAlias au lieu de AddHandler wsgi-script .wsgi :

<VirtualHost *:80>
    ...
    DocumentRoot /home/username/www/domain.tld/htdocs
    ...

    # %{DOCUMENT_ROOT} is needed because outside of directories,
    # REQUEST_FILENAME is the same as REQUEST_URI,
    # i.e '/foo', not '/physical/path/to/foo'
    #
    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ /site.wsgi/$1 [QSA,L,PT]

    WSGIScriptAlias /site.wsgi /home/username/www/domain.tld/deploy/site.wsgi
</VirtualHost>

Cela permettra de passer les requêtes aux fichiers statiques et de laisser WSGI s'occuper du reste.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X