W3C home > Mailing lists > Public > www-validator@w3.org > December 2002

Re: Link Checker Not Following Redirect (or some other problem?)

From: Ville Skyttä <ville.skytta@iki.fi>
Date: 06 Dec 2002 14:35:19 +0200
To: Joseph Reagle <reagle@w3.org>
Cc: webreq@w3.org, www-validator@w3.org
Message-Id: <1039178119.27613.80.camel@localhost.localdomain>

On Fri, 2002-12-06 at 00:40, Joseph Reagle wrote:
> Looking at:
> http://validator.w3.org/checklink?uri=http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html&recursive=on
> 
> 1. It looks like it's checking links for '/' and '/Overview.html' (with 
> recursive on)?

Yes, when invoked from the web, checklink limits the recursion scope so
that when recursively checking <http://foo.bar.org/quux/something>, only
documents below <http://foo.bar.org/quux/> are checked.  When invoked
from command line, the -l option can be used for specifying the scope.

> 2. It's complaining about two fragment identifiers as discussed below.

Hmm.  Just guessing; I think it does follow the redirect, but doesn't
grok the response.  When retrieving <http://www.w3.org/2000/09/xmldsig>,
I always get redirected (303) to
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd>,
which is served as application/xml.  Checklink only checks text/html and
application/xhtml+xml docs, so it just reports the anchors as broken.

Assuming my guess is correct, the "coming soon fix" would be not to report
anchors broken when they weren't even checked, but to confess what
actually did (not) happen.

Regarding the Accept header, perhaps checklink should send something like

  Accept: application/xhtml+xml, text/html, */*;q=0.5

...by default.

See bugs 111, 112 and 113 at <http://www.w3.org/Bugs/Public/>, and thanks
for the feedback!

-- 
\/ille Skyttä
ville.skytta at iki.fi
Received on Friday, 6 December 2002 07:34:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 12:14:05 GMT