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]>
