- From: Miguel Garcia <miguel.garcia@fundacionctic.org>
- Date: Fri, 8 Feb 2008 09:44:00 +0100
- To: "Dominique Hazael-Massieux" <dom@w3.org>, <public-mobileok-checker@w3.org>
>>Hi, >> >>With the now implemented handling of HTTP errors reporting, the checker >>will now fail when making a link to a non-recognized content-type. >> >>Typical scenario: >> * the checker checks a link to an MP3 file >> * it thus makes a request with its known Accept header >> * the server doesn't recognize this as matching the allowed types for >>MP3 (audio/mpeg) >> * it thus returns a 406 Not Acceptable >> * which triggers "If the HTTP status represents failure (4xx), other >>than 404 or a request for authentication (e.g. 401), FAIL" >> >>This obviously is not the intended effect, since LINK_TARGET_FORMAT has >>a test specifically to check that linked resources are in an acceptable >>format, which raises at most a WARN. >> >>I think the FAILs in the HTTP Response handling should only be triggered >>when analysing the resource itself or one of its included resources >>(distinction we already make for basic auth). >> >>What do you think? >> >>Dom >> You are right. Furthermore reviewing mobileOk Basic Test 1.0 I have noticed there is a note in 3.10 LINK_TARGET_FORMAT stating "404 and 5xx HTTP status do not result in failure when conducting this test". We could expand this note to cover all 4xx and 5xx HTTP status. Changes in checker code should be really easy just adding a condition so linked resources don't report FAIL in these cases. Miguel and Abel
Received on Friday, 8 February 2008 08:43:21 UTC