The following reply was made to PR general/5404; it has been noted by GNATS.
From: "William Colburn (aka Schlake)" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/5404: Apache seems to back-search bad URLS until it finds a good one, and returns it. This breaks things, such as my htdig search engine Date: Wed, 1 Dec 1999 12:57:36 -0700 On Wed, Dec 01, 1999 at 05:04:58PM -0000, [EMAIL PROTECTED] wrote: > Synopsis: Apache seems to back-search bad URLS until it finds a good one, > and returns it. This breaks things, such as my htdig search engine > > State-Changed-From-To: open-closed > State-Changed-By: marc > State-Changed-When: Wed Dec 1 09:04:56 PST 1999 > State-Changed-Why: > That is the correct behaviour. When SSIs are enabled, this is a feature > that allows SSIs to use PATH_INFO to do different things. I forwarded this to the htdig developers, and I agree with their response that apache seems to be doing the wrong thing here. If SSI's are turned on, and someone accidentally puts a / after an html document then all of a sudden all the relative URLs in that document are broken. Here is the response (snipped) from one of the htdig people back to me: >From: Gilles Detillieux <[EMAIL PROTECTED]> >Subject: Re: htdig reindexes the same page over and over (PR#714) >To: [EMAIL PROTECTED] (William Colburn) >Date: Wed, 1 Dec 1999 13:12:54 -0600 (CST) >I still think this in incorrect behaviour on the part of Apache! >It breaks any relative URLs in the document that the server returns for >the faulty URL. > >You gave the example of http://www.apache.org/index.html/eeep, which >does load the index.html page, but two of the three graphics don't load >because they use relative paths. Also, most of the links on that page >are broken because they too are relative. > >For this feature to work correctly, it would have to either send a >redirect to the client so it could load the page using the correct URL, >or it should parse all relative URLs in the document and convert them >to the correct absolute paths before giving the substitute document to >the client. Giving the client a substitute document with relative URLs >that it can't use is just wrong, and it's asking for trouble. -- William Colburn, "Sysprog" <[EMAIL PROTECTED]> Computer Center, New Mexico Institute of Mining and Technology http://www.nmt.edu/tcc/ http://www.nmt.edu/~wcolburn