On Tue, 2008-11-11 at 13:24 +0100, Jan Sievers wrote: > Hi everyone, > > I can't find a clear statement in the Apache 2.2 documentation about the > following scenario: > > I have the following configuration for index files: > > DirectoryIndex index.cgi > > > The request > > domain.tld/dir_containing_index_cgi/ > > works as expected. > > Now, since CGI defines the PATH_INFO mechanism, > (See section 4.1.5. in http://www.ietf.org/rfc/rfc3875) > the request > > domain.tld/dir_containing_index_cgi/index.cgi/foo > > results in execution of index.cgi with the meta-variable > > PATH_INFO set to "foo". > > *The question now is*: > > Is Apache 2.2 supposed to evaluate requests like > > domain.tld/dir_containing_index_cgi/foo > > so that the index.cgi is executed with the meta-variable > > PATH_INFO set to "foo"? No, apache will see that as a request for the entity at /dir_containing_index_cgi/foo. If you wanted that behaviour, you could alias the actual CGI. Eg, if your CGI file was /cgi-bin/foo.cgi, you could Alias /cgi-bin/foo.cgi /my-app Then requests for /my-app/foo would have the PATH_INFO set as you would imagine. > > Here it gives me a 404 error, saying it cannot find the specified > resource. I just want to be sure, that it is not a configuration > mistake, that prevents requests like that to function. > > For me the PATH_INFO mechanism is stupid anyway since I don't see any > advantage over the QUERY_STRING mechanism which is defined too. > > But nevertheless it is defined and used. Well, if you followed my example, you could also have a request for /my-app/foo/bar/quuz?wibble=yes, which would have PATH_INFO="/bar/quuz" and QUERY_STRING="wibble=yes" (roughly speaking!) > > With warm regards, > Jan Sievers > Cheers Tom --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx