httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: PATH_INFO with filters (was: Apache 2 directory/files)
Date Tue, 11 Dec 2001 03:13:56 GMT
From: "Joshua Slive" <joshua@slive.ca>
Sent: Monday, December 10, 2001 8:39 PM


> This also seems to be a problem for mod_include.
> 
> My naive analysis--without looking at the code--is that, since the core
> handler is serving the files, they are treated as static and not allowed
> PATH_INFO, even though they will be parsed by a dynamic filter.

That's correct for the default handler

The mod_dir DirectoryIndex code was just fixed to capture query args.

sub_req_lookup_file/dirent have a problem, there is no trivial way to
'tack on' the path info/query args from the original URI in a module such
as mod_negotation.  We could fall back on sub_req_lookup_uri, tacking back
on the path info and escaped query args, dunno if that makes the most
sense.  I solved in mod_dir by always readding the query args to each test
DirectoryIndex entry, so we don't sporadically 'fall off' the DirectoryIndex 
request into autoindex as we used to for requests like somewhere?M=D.

> It seems like the simplest (and perhaps best) answer to this problem is
> simply to have a directive that turns on or off the ability to have
> PATH_INFO (AllowPathInfo).  People have asked for such a thing
> under 1.3, since it is useful to prevent the profileration of absurd URLs
> and infinite loops in web crawlers.

I thoroughly hate this suggestion.  I'd rather identify such documents in some 
way as AcceptsPathInfo within a filter's fixups before the request is run.
IBM already ate a bit of dirt on this same hairbrained approach, I don't think
we want to follow.  Our own website, with it's .shtml approach, really sucked
because relative paths could be made un-relatated.

There was a related question about POST data and SSI requests.  Here too, one
Virtual include may be willing to accept the POST data.  If there were some
way to designate it as such, we should work at this, even if it is another
(ugh!) directive.

An essential problem is this; filters aren't everything.  In the end one should
have a handler to consume what the client gives us, be it path_info, query_args
or POST data.  But that seems against the direction we've been moving.

Bill


Mime
View raw message