Note: There are a few cases of duplicates in user autocompletion which are being worked on.

W3C link checker reports links to mozilla.org as broken

VERIFIED FIXED

Status

mozilla.org Graveyard
Server Operations
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: Jesse Ruderman, Assigned: Dawn Endico)

Tracking

Details

(URL)

(Reporter)

Description

16 years ago
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
(Assignee)

Comment 1

16 years ago
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.
Assignee: rko → endico

Comment 2

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
Making this bug depend on 
Bug 85499: HEAD http://mozilla.org returns "404 Not Found"
Depends on: 85499

Comment 7

15 years ago
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).
(Assignee)

Comment 8

15 years ago
if you can provide details for fixing the current install, that
would be great.

Updated

15 years ago
Blocks: 187809
(Reporter)

Comment 9

14 years ago
WFM.  The W3C link checker no longer complains about links to mozilla.org.  It
does complain about links to amazon.com, though :)
WFM here too.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Comment 11

14 years ago
Verified
Status: RESOLVED → VERIFIED

Comment 12

14 years ago
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) :-)
right, this FIXED
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
re-resolving
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
re-verifying
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.