2011/5/3 Graham Dumpleton <[email protected]>:
> 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.
That should be:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/site.wsgi/
RewriteRule (.*) site.wsgi/$1 [QSA,L,PT]
Regards, Clodoaldo
>
> 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.
>
>
--
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.
