- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Sat, 1 Jan 2011 20:42:40 +0200
- To: Henrik Rosenø <henrik.roseno@webspeed.dk>, <www-validator@w3.org>
Henrik Rosenø wrote: > Checklink reports the following when analyzing > http://www.transformation.dk/Skaberens- > intention.html : > > Line: 137 http://ing.dk/artikel/103831-meta-science-hvem-er-du > 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: > http://ing.dk/artikel/103831-meta-science-hvem-er-du#p219413 (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 Referer: http://validator.w3.org Host: ing.dk 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 http://mobil.ing.dk/artikel/103831 > 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 behavior). -- Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Saturday, 1 January 2011 18:44:22 UTC