On 4 May 2011 10:38, boscop <[email protected]> wrote: > The usage of the WSGIScriptAlias directive in the example on that site > specifies that the files in the given directory are WSGI applications. > The second example says how to restrict it to just files with > the .wsgi extension. I'm basically doing the same already with: > > AddHandler wsgi-script .py > > However, as I said above this doesn't take care of the path handling > and just makes each file a WSGI application. Also there is no way to > specify a fallback application for files that can't be found, that's > why I tried to use RewriteRules for that.
Did you actually read down to the bottom of the section titled 'The Apache Alias Directive' and which the URL I gave referenced? Part way down into the section it starts talking about AddHandler and mod_rewrite. > I seem to have found a solution in your post about fallback resource > here: > http://code.google.com/p/modwsgi/issues/detail?id=184 Which is what the documentation I pointed at gives. The documentation contains a better explanation than the ticket. > When there is only one application, SCRIPT_NAME won't change, so that > won't be a problem. The SCRIPT_NAME fixup is important because if the WSGI application constructs an absolute URL based on algorithm at: http://www.python.org/dev/peps/pep-3333/#url-reconstruction then you will get wrong SCRIPT_NAME. Specifically, index.py will appear in constructed URL, which isn't what you want. That SCRIPT_NAME fixup itself may potentially need to be changed where done in .htaccess file, can't remember. > But I noticed that for requests like example.com/foo, the PATH_INFO > is /public_html/foo instead of /foo so I changed it to As I said, the rewrite rule in the example would need to change as wasn't written originally for use in .htaccess file. Graham > RewriteEngine On > RewriteCond %{REQUEST_FILENAME} !-f > RewriteRule ^public_html(.*)$ /index.py/$1 [QSA,PT,L] > > Now everything seems to work. Thanks! > > On May 4, 1:54 am, Graham Dumpleton <[email protected]> > wrote: >> The documentation at: >> >> http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apa... >> >> shows the normal way that one would configure mod_wsgi if using >> AddHandler/mod_rewrite. >> >> That mod_rewrite rule though is specified based on it being in >> Directory directive inside main Apache httpd configuration files, so >> likely would need to be modified to work in .htaccess file. >> >> Important to note is that mod_rewrite rule in documentation works >> quite differently to what you are using. Specifically it says that if >> no static resource found, then fallback to routing request via >> designated WSGI application. To ensure that this works properly when >> application generates URLs for redirection etc, you need the >> documented fixup in the WSGI script file. >> >> As to your 500 error when using the ErrorDocument message, this is >> because your server configuration has specified ErrorDocument >> directives which refer to error pages or handlers which don't exist >> and so it had a 404 error trying to find the error document. Apache >> treats that as a secondary 500 error. If the ErrorDocument directives >> refer to stuff outside of your area, the system administrators have >> screwed up Apache configuration in turning them on but not referring >> to actual error pages or handlers for them. If the ErrorDocument >> directives look into your area, you will need to provide the error >> pages for URL they try and map to. If you use that mod_rewrite rule >> from documentation, then you just need to put static pages in >> directory at appropriate location and should be okay. If not, then >> request for error page would end up with your web application and it >> would have to provide them, which is probably not what you want. >> >> So, ask your system administrators what ErrorDocument directives are >> set to as they apply to your area and what requirements if any are on >> your to supply your own error pages to satisfy them. >> >> BTW, I hope this isn't a shared system because in .htaccess you can >> setup use of daemon mode and if running embedded mode then you run >> inside of Apache processes with other users code, which is generally a >> very bad idea on shared systems. So, is this your own Apache instance? >> >> Graham >> >> On 3 May 2011 17:58, boscop <[email protected]> wrote: >> >> >> >> > Hi, >> > I'm on a free shared hosting account where I have no access to >> > httpd.conf, but .htaccess. I have no shell access, but FTP and cPanel. >> > Python is available via mod_python and mod_wsgi. I want to use one of >> > the WSGI frameworks for my site. They all require that there is >> > exactly one WSGI application (usually specified with >> > 'WSGIScriptAlias / /path/to/app.wsgi' but this would only work in >> > httpd.conf) which gets the requested path passed in >> > environ['PATH_INFO']. Currently I have 'AddHandler wsgi-script .py' >> > set in .htaccess, but this would cause apache to resolve the path and >> > look for a wsgi script at that location, instead of passing the path >> > to the main application. All frameworks that I checked out are based >> > on there being only one application though (!). So I tried to use >> > mod_rewrite to achieve the passing of the path to the main application >> > like this: >> >> > RewriteEngine On >> > RewriteRule ^(.*)$ /absolute/path/to/index.py$1 [QSA,L,PT] >> >> > However, this causes an internal server error (500) on any request, >> > and it says "More information about this error may be available in the >> > server error log. Additionally, a 500 Internal Server Error error was >> > encountered while trying to use an ErrorDocument to handle the >> > request.". But no error was logged! (I confirmed that error logging >> > usually works by removing that line and introducing other bugs. Also, >> > having multiple wsgi apps and requesting them individually works, >> > too). >> > This leads me to my question: What would I have to write in .htaccess >> > to cause apache to pass the requested path to the one WSGI application >> > so that it correctly appears in environ['PATH_INFO'] and so that it >> > also handles GET parameters correctly, (and why does the above line >> > prevent error logging)? >> >> > -- >> > 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 >> > athttp://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. > > -- 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.
