Received: (qmail 18387 invoked by uid 2012); 28 Dec 1998 11:54:24 -0000 Message-Id: <19981228115424.18386.qmail@hyperreal.org> Date: 28 Dec 1998 11:54:24 -0000 From: Radu Greab Reply-To: radu@netsoft.ro To: apbugs@hyperreal.org Subject: mod_dir doesn't handle requests which must be processed internally by mod_proxy X-Send-Pr-Version: 3.2 >Number: 3596 >Category: mod_dir >Synopsis: mod_dir doesn't handle requests which must be processed internally by mod_proxy >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Mon Dec 28 04:00:01 PST 1998 >Last-Modified: Wed Apr 21 10:30:00 PDT 1999 >Originator: radu@netsoft.ro >Organization: >Release: 1.3.3 >Environment: Linux 2.0.36 (RedHat 5.2), gcc version 2.7.2.3 >Description: We have a virtual site where the index pages are dynamically generated by some mod_perl scripts. So, we use currently something like this in httpd.conf: DirectoryIndex index.html Redirect /index.html http://this_server/index.perl permanent ProxyPass /index.perl http://mod_perl_server/index.perl For marketing, technical (whatever) reasons, we would like to use a setup where the users aren't redirected to index.perl, but mod_dir should handle this transparently. Something like this: DirectoryIndex index.perl index.html ProxyPass /index.perl http://mod_perl_server/index.perl The later setup doesn't work because mod_dir tries to be, unfortunately, too smart :) It does a subrequest for index.perl, and this subrequest returns with a status code of HTTP_OK. Nevertheless, mod_dir does an additional check to see if index.perl is a file, which gives a false result because index.perl is handled by mod_proxy and so, no file info is available. IMHO this file access check is wasteful because to serve a resource mod_dir makes anyway an internal redirect and if the status code for the subrequest was HTTP_OK, what good will bring the file access check? I would like if mod_dir will drop the file access check. Thank you! >How-To-Repeat: I suppose that the information in description is enough, otherwise i'll prepare a complete example. >Fix: --- src/modules/standard/mod_dir.c.orig Mon Dec 28 12:24:56 1998 +++ src/modules/standard/mod_dir.c Mon Dec 28 13:00:35 1998 @@ -161,7 +161,7 @@ char *name_ptr = *names_ptr; request_rec *rr = ap_sub_req_lookup_uri(name_ptr, r); - if (rr->status == HTTP_OK && rr->finfo.st_mode != 0) { + if (rr->status == HTTP_OK) { char *new_uri = escape_uri(r->pool, rr->uri); if (rr->args != NULL) >Audit-Trail: From: Radu Greab To: apbugs@hyperreal.org, apache-bugdb@apache.org Cc: Subject: Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy Date: Mon, 28 Dec 1998 15:48:54 +0200 I understood finally for what's used the file access check. Sorry for the errors in the posted bug report. Still I need mod_dir to recognize indexes which must be processed later by mod_proxy, so the following patch should do it: --- src/modules/standard/mod_dir.c.orig Mon Dec 28 15:39:01 1998 +++ src/modules/standard/mod_dir.c Mon Dec 28 15:38:15 1998 @@ -161,7 +161,8 @@ char *name_ptr = *names_ptr; request_rec *rr = ap_sub_req_lookup_uri(name_ptr, r); - if (rr->status == HTTP_OK && rr->finfo.st_mode != 0) { + if (rr->status == HTTP_OK && + (rr->finfo.st_mode != 0 || rr->proxyreq != 0)) { char *new_uri = escape_uri(r->pool, rr->uri); if (rr->args != NULL) State-Changed-From-To: open-closed State-Changed-By: dgaudet State-Changed-When: Tue Apr 20 22:10:10 PDT 1999 State-Changed-Why: No, you have to fill in r->finfo if you're implementing something which pretends to be the filesystem... that's just how it is. You don't have to fill in much, just set the mode and mtime or something like that. I know, it's not well documented, but what of the api is? Dean From: Radu Greab To: dgaudet@apache.org Cc: apbugs@apache.org Subject: Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy Date: Wed, 21 Apr 1999 15:15:07 +0300 (EEST) dgaudet@apache.org writes: > No, you have to fill in r->finfo if you're implementing > something which pretends to be the filesystem... that's > just how it is. You don't have to fill in much, just > set the mode and mtime or something like that. I know, > it's not well documented, but what of the api is? Do you suggest that just because I need to transparrently provide dynamic content from another server I have to create bogus files on the filesystem? To solve my problem I have a few possibilities: 1) use my patch against mod_dir to make it proxy aware. The advantage is that I can use a minimum configuration in httpd.conf (one line) and it doesn't require _bogus_ files and the task can be solved with two modules compiled in: mod_dir and mod_proxy. 2) use mod_rewrite with proxy pass through feature and create a _bogus_ file to make mod_dir happy. Easy to implement but requires a more complex configuration in httpd.conf (two or three lines) and _bogus_ files. The task can be solved with three modules compiled in: mod_dir, mod_proxy and mod_rewrite. 3) the index file could be a cgi script which passes the request further as a proxy request to the other server, even if I have mod_proxy which could do the task. Ugly. It seems that making mod_dir aware of proxy requests by applying this patch is the most clean and elegant solution. What do you think? Thanks, Radu Greab. From: Dean Gaudet To: Radu Greab Cc: apbugs@apache.org Subject: Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy Date: Wed, 21 Apr 1999 10:20:45 -0700 (PDT) On Wed, 21 Apr 1999, Radu Greab wrote: > dgaudet@apache.org writes: > > No, you have to fill in r->finfo if you're implementing > > something which pretends to be the filesystem... that's > > just how it is. You don't have to fill in much, just > > set the mode and mtime or something like that. I know, > > it's not well documented, but what of the api is? > > Do you suggest that just because I need to transparrently provide > dynamic content from another server I have to create bogus files on > the filesystem? No I wasn't saying that. I'm saying if a content handler provides file-like objects it needs to fill in r->finfo.st_mode and r->finfo.st_mtime. It doesn't need to create files to do that. > To solve my problem I have a few possibilities: > 1) use my patch against mod_dir to make it proxy aware. The advantage > is that I can use a minimum configuration in httpd.conf (one line) and > it doesn't require _bogus_ files and the task can be solved with two > modules compiled in: mod_dir and mod_proxy. The bug isn't in mod_dir, it's in mod_proxy. mod_dir follows the API. Dean >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]