RE: Failure on unrecognized format for LINK_TARGET_FORMAT

>>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