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.