httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wilson <>
Subject Re: Patch go boom...
Date Tue, 10 Oct 1995 12:02:22 GMT
> > Mmm, 
> > 
> > 	04a_ExtraPath.0.8.14.patch
> > 
> > For 04a_ExtraPath.0.8.14.patch Ben L writes:
> > 
> > 	Changelog: Prevent Apache from serving /x/y/z/a as /x/y when z/a
> > 		doesn't exist.
> > 
> > I sort of thought we'd already hammered this out a couple of rounds ago.
> > I recall Rob H and I fussing because we both knew of code that used to
> > expect a /x/y CGI-BIN script to be passed /z/a as PATH_INFO.  Rob H, you
> > wanna confirm?
> > 
> > Ben, do you want to compare this with:
> > 
> >
> > 
> > where PATH_INFO == /foo/bar
> > 
> > Or am I missing summink.


> Yep. This patch does not affect cgi scripts PATH_INFO stuff. The patch
> prevents ordinary pages from exhibiting this bizarre behaviour.

But, but...  it's not bizarre.  For a URL like:


there's a web resource called foo.html which can receive /bar/baz as PATH_INFO.
If foo.html is a SSI-enabled page (chmod u+x, or renamed to *.shtml) then
PATH_INFO is passed to the SSI environment and everyone's happy.  In this
sense foo.html is working as a script.

But if foo.html is just a regular page (no SSI) then why should the server
behave differently?  Specifically, why should the browser be made to care
whether or not the resource can make use of the additional path information?

A counter argument would be:

	"Sure, then what's to stop people from sending URLs like:

and my response would be:

	"Provided there's an 'aaaa' or 'aaaa/any' or 'aaaa/any/old' etc,
	etc, then it doesn't matter.  Search the URL from left to right
	stopping at the last matching resource (.html, .shtml, .cgi) and
	everything remaining to the right is for the resource to deal with."

> I think I remember someone saying that PATH_INFO can be used by SSI,
> so is the patch still necessary? 

Well, I was confused.  This patch has no effect if foo.html is SSI
enabled.  But that's not the point.

I don't like this patch ;)  But I wonder if we all agree about what URLs
really mean.  For my argument a URL != UNIX file, and I believe we'd be
limiting the flexibility of the server by adding this new behaviour.

Any offers?  Perhaps Roy F's got a clue here?


View raw message