DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14648>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14648 mod_rewrite does not proxy included requests ------- Additional Comments From [EMAIL PROTECTED] 2002-11-27 20:08 ------- I've done some more digging and think I've come a little closer to the real source of the problem: mod_dir makes subrequests for each of its potential index file names until it finds one to return. Line 165 of mod_dir.c is this: if (rr->status == HTTP_OK && S_ISREG(rr->finfo.st_mode)) { So, for mod_dir to return an index file the subrequest has to be HTTP_OK and it must be a regular file. This works fine with the unpatched mod_rewrite, because it will return HTTP_OK and the file will be there -- even if the server is going to end up proxying it in the end. But, if you patch mod_rewrite then you'll still get the HTTP_OK, but rr->filename will have been changed to start with "proxy:", so S_ISREG() will fail. Which leads to this solution: change the call to ap_sub_req_lookup_uri on line 163 of mod_dir.c to ap_sub_req_lookup_file. ap_sub_req_lookup_file doesn't do the URI translation, so it skips mod_rewrite in the subrequest. But then mod_dir still does an internal redirect, which in turn *does* do the URI translation, so everything works out in the end. With these changes both mod_include and mod_dir do the right thing when they are dealing with a file proxied via mod_rewrite+mod_proxy. I'll attach a patch which changes both parts. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
