Yeah it seems to send the correct header now. Thanks. I'll run
linkchecker again on winehq maybe tomorrow.
Le mercredi 02 novembre 2005 à 16:14 -0600, Jeremy Newman a écrit :
I've run into this before. Problem is that if I use a local URL it
breaks the website images for the 404 page. This is due to the local
path not matching what the URL reads. I get around it by using the
redirect.
I did fix the code in the website so when the 404 page is loaded, it
correctly sends the 404 header. Let me know if that works better for
you.
On Wed, 2005-11-02 at 11:26 +0100, Jonathan Ernst wrote:
http://httpd.apache.org/docs/1.3/mod/core.html#errordocument
Note that when you specify an ErrorDocument that points to a remote URL
(ie. anything with a method such as http in front of it), Apache *will
send a redirect to the client to tell it where to find the document,
even if the document ends up being on the same server*. This has several
implications, the most important being *that the client will not receive
the original error status code*, but instead will receive a redirect
status code. This in turn can confuse web robots and other clients
which try to determine if a URL is valid using the status code.
I was using linkchecker (http://linkchecker.sourceforge.net/) to check
for deadlinks and wondered why some people could still find some
deadlinks on winehq. That's because our 404 handler doesn't send an
Error 404 message to the user agent.
This change will make apache send a 404 instead of a redirect and will
let the original address in the browser's address bar instead of
changing it to the /site/404 file. It will also make it easier to check
for deadlinks as the error code will be correct now.
--
Jonathan Ernst [EMAIL PROTECTED]
