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

Reply via email to