Sorry for taking so long to reply. If you want me to look at this further, would need to see the rewrite rules you are using and the mod_wsgi configuration used. Not sure how much time I will have to look at it as next few weeks going to be quite busy as travelling to US for PyCon.
Graham On 23 February 2011 06:11, bc <[email protected]> wrote: > Ah, you're right, it's happening for other requests, too, that don't > use file_wrapper. > > I'm still puzzled. It's not generating a subrequest on the rewritten > path. It's generating a subrequest after removing the wsgi alias > prefix, and after mod_rewrite reports passing the request to the next > handler. So this is after apache has identified the request as > matching the wsgi alias mount point. It's unclear to me why a > subrequest here would ever be appropriate. > > If I do a rewrite to a file (e.g. an image), there's no subrequest. It > just serves the file in the context of the initial request. So it's > something about the interaction between apache and mod_wsgi. > > > On Feb 16, 6:09 pm, Graham Dumpleton <[email protected]> > wrote: >> Sorry for taking so long to reply. Been very busy couple of weeks and >> things that required a bit of thought or looked a but complicated have >> been falling through the cracks. >> >> On 15 February 2011 04:11, bc <[email protected]> wrote: >> >> > I'm using wsgi.file_wrapper to serve secured media in the context of >> > wsgi (the important part being that wsgi can run as a different user). >> > I notice in the mod_rewrite logs that when I do this, the file path >> > passes through apache as a subrequest with the wsgi mount point >> > stripped off. >> >> The mod_wsgi implementation of wsgi.file_wrapper does not issue a >> subrequest and so mod_rewrite should not be getting triggered for a >> sub request due to that. All I can say is that it is likely >> mod_rewrite just doing something odd in fixup phase just before >> mod_wsgi content handler is run. >> >> What do you see of a request where wsgi.file_wrapper isn't being used? >> >> Graham >> >> >> >> > That is, if the original request is /wsgiscriptalias/securedOne/ >> > foo.gif, there's a wsgi script alias of /wsgiscriptalias, and I return >> > file_wrapper of securedOne/foo.gif, I see a subrequest of /securedOne/ >> > foo.gif passing through mod_rewrite. >> >> > I find this a bit weird, since the uri isn't really "valid", in the >> > sense that it doesn't match any configured directory or location in >> > apache. mod_rewrite logs it passing through, like so: >> >> > [perdir /var/www/html/] pass through /var/www/html/securedOne >> >> > which doesn't exist. Then mod_wsgi serves the file. >> >> > I'm a bit concerned about security (not knowing what kind of weird uri >> > manipulations might be possible here, and how it interacts with apache >> > security), though in one way it's working in my favor: if the uri came >> > through in the original form, it might cause a loop, dispatching the >> > url to wsgi again, creating another subrequest, then to mod_rewrite, >> > etc., etc. >> >> > I'm wondering if this is again related to SCRIPT_NAME problems with >> > mod_rewrite. >> >> > Also wondering what it's *supposed* to be doing when it travels >> > through apache as a subrequest, i.e. how is it supposed to be a valid >> > uri w/o causing a loop? > > -- > 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.
