Last Comment Bug 80122 - W3C link checker reports links to mozilla.org as broken
: W3C link checker reports links to mozilla.org as broken
Status: VERIFIED FIXED
:
Product: mozilla.org Graveyard
Classification: Graveyard
Component: Server Operations (show other bugs)
: other
: x86 Windows 98
: -- normal (vote)
: ---
Assigned To: Dawn Endico
: Dawn Endico
Mentors:
http://validator.w3.org/checklink?uri...
Depends on: 85499
Blocks: 187809
  Show dependency treegraph
 
Reported: 2001-05-10 15:41 PDT by Jesse Ruderman
Modified: 2015-03-12 08:17 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Jesse Ruderman 2001-05-10 15:41:42 PDT
When I use the W3C link checker (http://validator.w3.org/checklink/) on any of 
my pages that link to http://www.mozilla.org/, the link checker reports that 
mozilla.org returned a 404 error.

Here's a page to test the link checker with:
http://www.cs.hmc.edu/~jruderma/mozilla/testlinks.html
Comment 1 Dawn Endico 2001-05-10 16:28:47 PDT
clicking on the above linkx at validator.w3.org causes these entries in
the error log.


[10/May/2001:15:48:55] warning (  258): for host 18.29.1.50 trying to HEAD /,
send-error reports: error opening /e/docs/error.html (No such file or directory)
[10/May/2001:15:48:56] warning (  258): for host 18.29.1.50 trying to HEAD
/credits/, send-error reports: error opening /e/docs/error.html (No such file or
directory)
[10/May/2001:15:49:02] security (  258): for host 194.213.34.219 trying to LINK
/projects/, acl-state reports: access of /e/docs/projects/ denied by ACL (null)
directive 0
[10/May/2001:15:49:05] warning (  258): for host 18.29.1.50 trying to HEAD
/newsbot, send-error reports: error opening /e/docs/error.html (No such file or
directory)

However, those links are valid and work. I believe that validator is just
whining that our server doesn't respond to HEAD the way they want it to.
That's a problem with validator, not us. I'm inclined to invalidate this
but it would be good to either add something to /e/docs/error.html or 
fix the server to use the standard error message.
Comment 2 Michael Nahrath 2001-07-14 09:49:37 PDT
Same behaviour with <http://valet.webthing.com/link.html>

> I believe that validator is just
> whining that our server doesn't respond to HEAD the way they want it to.

The question is: 
Why doesn't the mozilla.org webserver respond to HEAD queries the way other
software expects? 
This is -at least- very uncommon. Is mozilla.org violating the http:-Specs? 
Or are these link-checkers taking incorrect assumptions?
Comment 3 Terje Bless 2001-07-14 11:36:16 PDT
www.mozilla.org is returning a 404 response to HTTP 1.0 HEAD requests. 
The W3C link checker is simply reporting this. So would a browser if it 
tried to do a HEAD on the URI in question -- to check if it had changed, say 
-- and so will anything else that expects a HTTP server to speak HTTP. 

Why in the world doesn't mozilla.org respond properly to HTTP HEAD 
requests?
Comment 4 Gerald Oskoboiny 2001-07-14 11:59:33 PDT
notes from the HTTP/1.1 spec:

    The methods GET and HEAD MUST be supported by all general-purpose           servers.                                                                      -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1                                                                                    The HEAD method is identical to GET except that the server MUST NOT         return a message-body in the response. The metainformation contained        in the HTTP headers in response to a HEAD request SHOULD be identical       to the information sent in response to a GET request.                        
     -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4        
(HTTP/1.0 probably says something very similar)
Comment 5 Gerald Oskoboiny 2001-07-14 12:07:18 PDT
er... sorry about the lack of newlines in my previous comment. (I wish
bugzilla had a 'preview' feature) I'll try that again:

notes from the HTTP/1.1 spec:

    The methods GET and HEAD MUST be supported by all general-purpose
    servers. 
      -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1

   The HEAD method is identical to GET except that the server MUST NOT
   return a message-body in the response. The metainformation contained
   in the HTTP headers in response to a HEAD request SHOULD be identical
   to the information sent in response to a GET request.
     -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4
Comment 6 Andreas Franke (gone) 2001-09-02 21:49:41 PDT
Making this bug depend on 
Bug 85499: HEAD http://mozilla.org returns "404 Not Found"
Comment 7 Joe McCabe 2002-05-07 18:34:00 PDT
I believe that the HEAD problem can be fixed very easily by simply fixing the
current NES3.6 config (I can provide details if needed). The LINK problem is a
defect in NES3.6 and requires upgrading to NES3.6sp3 (or NES6.1 if I had my way).
Comment 8 Dawn Endico 2002-05-07 18:52:10 PDT
if you can provide details for fixing the current install, that
would be great.
Comment 9 Jesse Ruderman 2003-10-12 01:52:44 PDT
WFM.  The W3C link checker no longer complains about links to mozilla.org.  It
does complain about links to amazon.com, though :)
Comment 10 Simon Paquet [:sipaq] 2004-02-08 09:23:01 PST
WFM here too.
Comment 11 Brant Gurganus 2004-02-08 10:02:49 PST
Verified
Comment 12 Terje Bless 2004-02-08 10:36:22 PST
Resolution should be FIXED; www.mozilla.org is now Apache 1.3.27 instead of the borken NES 
installation it used to be. This was never a issue with the W3C Link Checker; it was always a server 
issue.

(just so anyone searching Bugzilla will get the right info) :-)
Comment 13 Simon Paquet [:sipaq] 2004-02-08 10:49:39 PST
right, this FIXED
Comment 14 Simon Paquet [:sipaq] 2004-02-08 10:50:06 PST
re-resolving
Comment 15 Simon Paquet [:sipaq] 2004-02-08 10:50:31 PST
re-verifying

Note You need to log in before you can comment on or make changes to this bug.