On 24 December 2010 09:17, Jason Garber <b...@gahooa.com> wrote: > Hi Graham, > WSGIScriptAlias /Foo /path/to/foo.wsgi > WSGIScriptAlias /Bar /path/to/bar.wsgi > WSGIScriptAlias / /path/to/root.wsgi > Alias /Static /path/to/static > In the above config, are the following assumptions correct? > /foo* go to foo.wsgi > /bar* go tp bar.wsgi > /static* go to the static dir > every thing else go to root.wsgi > If not, please point out my error.
Yes except for couple of clarifications. /Foo and /Foo/ and /Foo/* to foo.wsgi /Bar and /Bar/ and /Bar/* to bar.wsgi /Static will get redirect by Apache to /Static/ /Static/ if configured will get processed as directory listing again static dir or get mapped to index resource in that directory, or otherwise result in forbidden. /Static/* will be matched to resource with static directory and it none exist result in not found. If maps to sub directory, then trailing slash redirection and index resource processing as above for /Static is applied. Everything else goes to root.wsgi. Important things to not. Alias directives always take precedence over WSGIScriptAlias regardless of order of directives. Thus for: WSGIScriptAlias /subdir ... Alias / ... everything still goes through Alias and noting goes to what WSGIScriptAlias maps to. Within a set of Alias or WSGIScriptAlias directives, they are processed in order. Thus for: WSGIScriptAlias / ... WSGIScriptAlias /Foo ... WSGIScriptAlias /Bar everything will be sent through '/' even when to sub URL of /Foo or /Bar. This being because order is wrong. Graham > Thanks! > JG > > > On Thu, Dec 23, 2010 at 4:38 PM, Graham Dumpleton > <graham.dumple...@gmail.com> wrote: >> >> On 22 December 2010 18:04, Todd Wilson <twil...@csufresno.edu> wrote: >> > Graham Dumpleton wrote, on 12/21/2010 06:41 PM: >> >> On 22 December 2010 06:11, Todd Wilson <twil...@csufresno.edu> wrote: >> >>> The documentation contains some information on the interaction of the >> >>> mod_wsgi directives and the Apache directives, but, not being terribly >> >>> familiar with Apache configuration, I still have a couple of >> >>> questions. I'm trying to host a WSGI (actually Django) application on >> >>> a hosting provider, and only I have read access to the Apache >> >>> configuration file and the ability to add (approved) directives to the >> >>> end of it, via an included file. The existing configuration file is >> >>> mainly for PHP and mod_perl applications and is WSGI-unaware. There >> >>> are <Directory> blocks for an htdocs directory inside my home >> >>> directory and a cgi-bin subdirectory, as well as some <Files> >> >>> directives for specific files (like .htaccess, .htpasswd, and some >> >>> other special files). If I add my WSGI directives at the end, via the >> >>> included file, how will they interact with the earlier part of the >> >>> configuration? Will they override the earlier <Directory> and <Files> >> >>> blocks, or will I have to do something specific to achieve this? Will >> >>> URLs ending in .php still be served through mod_php? Also, I wonder >> >>> whether I should use their htdocs directory to serve my media files, >> >>> or whether I would be better off creating a separate directory for >> >>> that. >> >>> >> >>> Thanks for any advice you can provide! >> >> >> >> As long as WSGIScriptAlias is mounting at a sub url and not the root >> >> of the site, then there shouldn't be any conflict. >> >> >> >> It is when you want your WSGI application mounted at root of web site, >> >> but still have other stuff at sub URLs, eg., PHP files, that you may >> >> have a problem with the inability to add additional configuration into >> >> existing Directory blocks in configuration. >> >> >> >> At what URL were you intending to have Django application accessible >> >> as? >> > >> > Yes, I'd like to have my Django application accessible from the root. >> > The earlier configuration sets ServerRoot to my home directory, and >> > DocumentRoot to its "htdocs" subdirectory. It has directives such as >> > >> > <Files ~ "^\.ht(access|passwd)$"> >> > Order allow,deny >> > Deny from all >> > </Files> >> > >> > <Directory htdocs> >> > Options FollowSymLinks ExecCGI MultiViews Includes >> > AllowOverride all >> > Order allow,deny >> > Allow from all >> > </Directory> >> > >> > So, my questions become: >> > >> > 1. Will these (earlier) directives interfere with my intention to >> > serve my Django site from root? For example, what would Apache do >> > with URLs like /admin/.htpasswd or /index.php? >> >> They will not interfere as far as stopping mod_wsgi working, but >> WSGIScriptAlias will override DocumentRoot if mount point for >> WSGIScriptAlias is '/', ie., root of the site. In other words, >> everything would generally get routed into WSGI application instead. >> >> If your cgi-bin directory is setup using an Alias directive explicitly >> however rather than being a subdirectory of your personal htdocs then >> it will at least override WSGIScriptAlias for that sub URL. Ie,, Alias >> directives take precedence over WSGIScriptAlias. >> >> > 2. Assuming that Apache doesn't intercept .php files in this way, >> > would I be able to designate a subdirectory into which I could put >> > .php files, or .cgi files for that matter, and still have them >> > served the usual way with Apache? Or would I be forced to serve >> > my application from a sub url if I wanted to do this? (I know I >> > can serve static files this way with Alias, but does it work for >> > .php files, etc.?) >> >> You can use Alias directive to have CGI and PHP files under directory >> mounted as a sub URL, or if you avoid WSGIScriptAlias and use >> AddHandler means of setting up WSGI script, you may be able to simply >> interleave them within the existing DocumentRoot directory. >> >> See: >> >> >> http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apache_Alias_Directive >> >> Using mechanism described in latter half of that section, you can via >> that redirect have requests which map to actual PHP or CGI file routed >> to that file and then every other request map through to WSGI >> application. >> >> In other words, resources represented by physical files, be they PHP >> or CGI scripts, or even plain old static files, effectively overlay >> the WSGI application. >> >> Graham >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to modw...@googlegroups.com. >> To unsubscribe from this group, send email to >> modwsgi+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to modw...@googlegroups.com. > To unsubscribe from this group, send email to > modwsgi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to modw...@googlegroups.com. To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
