Re: checklink: False reporting of a 302 temporary redirect?

Henrik RosenÝ wrote:

> Checklink reports the following when analyzing
> intention.html :
> Line: 137
> Status: 302 -> 200 OK
> This is a temporary redirect. Update the link if you believe it makes
> sense, or leave it as is.
> Broken fragments:
> (line
> 137)
> But when I click that link manually on that page, I cannot observe
> any redirecting nor that the link is broken.

Checklink does not say that the link is broken; it just says it gets 
redirected. You might not directly see the redirection, but if you use e.g. 
Firefox with the Live HTTP Headers extension, you can see that indeed the 
page is delivered directly to the browser.

However, different user agents may get different responses, depending on the 
HTTP requests they send. If I send the simplest possible request, with just 
HEAD and Host commands, I get a direct response. But if I try to simulate 
the headers that Checklink checks, e.g. with

HEAD /artikel/103831-meta-science-hvem-er-du HTTP/1.1
Accept: text/html, application/xhtml+xml;q=0.9, 
application/vnd.wap.xhtml+xml;q=0.6, */*;q=0.5
Accept-Language: fi-fi,fi;q=0.8,en-us;q=0.5,en;q=0.3

then I get a 302 redirection. After some additional testing, I gather that 
it's the Accept header, and specifically the presence of the alternative 
application/vnd.wap.xhtml+xml there (even with a fairly low q value) that 
causes the difference, making the server redirect the user agent to the 
mobile version

> Is this an error in Checklink?

No. But there might be room for improvement.

Maybe Checklink should explicitly echo the HTTP headers it uses, but 
information about headers is given descriptively.

Maybe Checklink should send simpler headers. What's the point in sending 
such a complicated Accept header? What's the point in sending language 
preferences as set in the user's browser? Those preferences vary a lot among 
browsers and user agents.

"Checking links" is not a simple matter, since the responses may depend on 
the request headers. But if you ask me, checking should primarily be made 
using simple and neutral headers, by default at least, and for more thorough 
testing, variation of headers might be used (e.g., a small set of different 
Accept and Accept-Language headers, constructed to reflect typical browser 


Received on Saturday, 1 January 2011 18:44:22 UTC