Thanks Graham, it took me some time to figure it out but I've now got a suitable work around.
At first I had tried to move REDIRECT_URL to a different key and then getting Django to match the /handler404 URL. This resulted in some odd behaviour which I thought was worth commenting on. My browser would be issued with a redirect, though I'm not sure where this comes from (Django or Apache) it is definitely as a result of my adding a urlpattern to match /handler404 in Django. In some scenarios this would redirect to /handler404, in others Firefox would tell me I was stuck in a forwarding loop. However, by changing the PATH_INFO to the REDIRECT_URL and having Django match for the original URLs I have a working work-around (this is actually better as it gives me the option to match different parts of the original URL in the urlpattern, rather than only matching / handler404). It works fine to implement this as a Django request middleware or in a middleware outside of Django before it's had a chance to wreck things! Thanks again for your help! On Jul 19, 5:13 am, Graham Dumpleton <[email protected]> wrote: > Sorry for taking so long to reply, work is sucking up my free time as > well at the moment. > > The issue you are seeing may well relate to this bug in Django. > > https://code.djangoproject.com/ticket/12464#comment:14 > > Unfortunately a few days ago they marked it as closed as they can't > see that Django is doing the wrong thing. It isn't helped though by > fact that it isn't a simple thing to fix. > > What you may be able to do is use a special WSGI middleware wrapper > that adjusts the WSGI environ dictionary values as they get passed > through for the error document redirect, perhaps moving REDIRECT_URL > out of the way so that Django doesn't muck things up by trying to use > it, or otherwise modifying SCRIPT_NAME/PATH_INFO to values that make > things do what is necessary. > > Graham > > On 16 July 2011 03:16, ellonweb <[email protected]> wrote: > > > > > > > > > Thanks, this works very well; for reference, I'm able to get the > > original request url using REDIRECT_URL (which is accessible in > > django's request.META dict) > > > I still have one problem though in detecting the 404 url in the WSGI > > app (I'm using the same WSGI for multiple things, same environment > > etc), as it seems to vary in a peculiar manner: > > With "ErrorDocument 404 /handle_404", if my original request is / > > graphs/123, the reported path is /handle_404. /graphs/1234 gives // > > handler_404, /graphs/12345 gives /g/handler_404, ... /graphs/ > > 1234567890 gives /graphs/handler_404, and with more characters I start > > to get the 1234.. coming through as well! It seems that "/handler_404" > > just replaces the last 11 characters of the request. I realize that > > this is probably getting a bit out of the mod_wsgi territory, but any > > ideas how to solve this? Or suggestions to detect the 404 url > > differently? I know an obvious solution is to use a seperate wsgi app > > but it's useful to keep the code/environment combined. (Also, maybe > > this is actually just a bug in django's handling?) > > > Many thanks, > > > On Jul 15, 2:21 am, Graham Dumpleton <[email protected]> > > wrote: > >> Have you tried something like: > > >> Alias /images/ /some/path/images/ > > >> <Directory /some/path/images> > >> ErrorDocument 404 /handle_404 > >> </Directory> > > >> WSGIScriptAlias /handle_404 /some/path/scripts/handle_404.wsgi > > >> You will need to pick through the WSGI request environment to see > >> whether the target file for the original request is included. I can't > >> remember exactly if it is. > > >> The WSGI script can then generate the file to temporary location and > >> then when done move it into correct place and return it for that > >> request as response from the WSGI script application. > > >> Graham > > >> On 13 July 2011 14:58, ellonweb <[email protected]> wrote: > > >> > Hi, > > >> > I've got a WSGIScriptAlias set up in Apache, and I'm adding some new > >> > functionality at /graphs/ that generate some PNG graphs for my > >> > website. I want to set up a caching system for these graphs, however, > >> > rather than having to go all the way through WSGI/Python etc. to read > >> > the previously generated images, is there a way to configure Apache to > >> > look for a file matching the url in some location (for example I use > >> > some static images using a normal Alias), and if the files don't > >> > exist, have Apache fall back to the WSGI which will generate and > >> > output the PNG (and then save it to the file system for future > >> > requests that can be served directly by Apache)? Perhaps using the > >> > WSGI as a 404 handler? > > >> > Thanks in advance, > > >> > -- > >> > 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 > > 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.
