Feature #892
closedNo PATH_INFO/PATH_TRANSLATED when using FastCGI as an index generator
Description
I'm using a FastCGI to generate directory indexes, and having to map URIs (based on REQUEST_URI) to the filesystem myself, rather than using PATH_INFO and PATH_TRANSLATED; obviously this breaks when there are aliases involved.
Having PATH_INFO be non-blank and PATH_TRANSLATED be set at all would be useful.
Updated by Anonymous almost 17 years ago
Replying to aredridel:
I'm using a FastCGI to generate directory indexes, and having to map URIs (based on REQUEST_URI) to the filesystem myself, rather than using PATH_INFO and PATH_TRANSLATED; obviously this breaks when there are aliases involved.
Having PATH_INFO be non-blank and PATH_TRANSLATED be set at all would be useful.
Hey, I have the same issue - would be really nice if this would be fixed. Cheers
-- anders1
Updated by gstrauss over 8 years ago
- Description updated (diff)
- Category changed from core to mod_indexfile
- Status changed from New to Need Feedback
- Assignee deleted (
jan)
It looks like the code passes the requested info through to dynamic handlers.
Is this still an issue?
Updated by gstrauss over 8 years ago
I think I understand what you're asking: if PATH_INFO is not set, and your index generator is defined to be a docroot path beginning with '/', then you would like PATH_INFO and PATH_TRANSLATED set to the URI and physical paths of the directory.
What should be done in the case where PATH_INFO already exists?
e.g. /physical/dir/path_info/here where /docroot/physical/path/ is a directory under the docroot and /path_info/here is PATH_INFO.
Your index-generator currently gets /path_info/here as PATH_INFO in this case.
However, I think you're assuming no path info is present in the original request, and would like PATH_INFO set to /physical/path/ and the associated PATH_TRANSLATED to the physical path.
What should be done in the case where PATH_INFO already exists? Should it be discarded? Should it be appended to the "new" PATH_INFO that you requested (the original URL)? Neither feels right to me.
I think something else may provide a better solution than attempting to reuse existing concepts. If mod_indexfile handler begins with '/', the REQUEST_URI contains the URI, and perhaps we can add an environment variable with the physical path to the current directory. What would you think of "PATH_TRANSLATED_DIRINDEX"?
Updated by gstrauss over 8 years ago
- Tracker changed from Bug to Feature
- Status changed from Need Feedback to Patch Pending
- Target version set to 1.4.40
The following patch adds PATH_TRANSLATED_DIRINDEX to the environment when the mod_indexfile target is a path which begins with '/'. This allows CGI, FastCGI, SCGI index generators to know the physical path for which they were called, even after mod_alias translations.
This patch also fixes a bug where con->uri.path was a mishmash of original con->uri.path plus full mod_indexfile target, which was incorrect when the mod_indexfile target began with '/'.
diff --git a/src/mod_indexfile.c b/src/mod_indexfile.c index c0027b4..7a8f0f3 100644 --- a/src/mod_indexfile.c +++ b/src/mod_indexfile.c @@ -193,11 +193,21 @@ URIHANDLER_FUNC(mod_indexfile_subrequest) { continue; } - /* rewrite uri.path to the real path (/ -> /index.php) */ - buffer_append_string_buffer(con->uri.path, ds->value); - buffer_copy_buffer(con->physical.path, p->tmp_buf); + if (!ds->value || ds->value->ptr[0] != '/') { + /* rewrite uri.path to the real path (/ -> /index.php) */ + buffer_append_string_buffer(con->uri.path, ds->value); + } else { + buffer_copy_buffer(con->uri.path, ds->value); + + if (NULL == (ds = (data_string *)array_get_unused_element(con->environment, TYPE_STRING))) { + ds = data_string_init(); + } + buffer_copy_string_len(ds->key, CONST_STR_LEN("PATH_TRANSLATED_DIRINDEX")); + buffer_copy_buffer(ds->value, con->physical.path); + array_insert_unique(con->environment, (data_unset *)ds); + } - /* fce is already set up a few lines above */ + buffer_copy_buffer(con->physical.path, p->tmp_buf); return HANDLER_GO_ON; }
Updated by gstrauss over 8 years ago
- Related to Bug #448: SCRIPT_FILENAME and SCRIPT_NAME are wrong for [F]CGI scripts with full paths invoked as a directory index added
Updated by gstrauss over 8 years ago
- Status changed from Patch Pending to Fixed
Try using the new PATH_TRANSLATED_DIRINDEX if the index generator path is not relative to the current dir.
Also available in: Atom