Depends a bit on what you are doing. You do have to be a bit more careful with WSGIScriptAliasMatch if using that, as SCRIPT_NAME may not come out how you expect it. So, even though not substituting parts of URL into file system path for WSGI script file, you may still have to append in a substitution after the WSGI script file the match part of URL to get SCRIPT_NAME how you need it. Because what you may need to do is non obvious unless you test the result properly, usually better to avoid WSGIScriptAliasMatch.
Note that there is no harm in having multiple WSGIScriptAlias directives pointing at same WSGI script, even with same process-group and application-group options as it is smart enough to know that script already preloaded from first and will not load it a second time. Graham On 13 May 2011 08:10, Kent <[email protected]> wrote: > I will stay with WSGIScriptAlias then, but the question still remains: > are there any reasons to avoid having more than one of these point to > the same script as I have done? > > On May 12, 6:03 pm, Graham Dumpleton <[email protected]> > wrote: >> On 13 May 2011 02:09, Kent <[email protected]> wrote: >> >> > Is there any reason to avoid having more than one WSGIScriptAlias >> > directive point to the same preloading script: >> >> > WSGIScriptAlias /tg /home/app/trunk/src/appserver/wsgi-config/wsgi- >> > deployment.py process-group=app application-group=%{GLOBAL} >> > WSGIScriptAlias /debug/tg /home/app/trunk/src/appserver/wsgi-config/ >> > wsgi-deployment.py process-group=app application-group=%{GLOBAL} >> >> > I imagine I can use WSGIScriptAliasMatch for preloading and have only >> > one directive, is there any reason to avoid having more than one >> > WSGIScriptAlias ? >> >> Because for WSGIScriptAliasMatch the target WSGI script path can >> contain substitution patterns dependent on what was matched from the >> URL, one cannot preload the WSGI script file up front. Thus, >> preloading of a script when using process-group and application-group >> options only works for WSGIScriptAlias and not WSGIScriptAliasMatch. >> >> One may theoretically be able to scan the WSGI script path used with >> WSGIScriptAliasMatch and work out if any substitutions occur in it, >> and so still preload it, but then you possibly end up with may be >> confusing behaviour in that sometimes in preloads and other times not >> for the same directive. Thus simpler to say that preloading works for >> WSGIScriptAlias but not WSGIScriptAliasMatch for case where >> process-group and application-group both supplied. >> >> Graham > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
