Re: Clarifications on HTTP Response tests

Hi Francois,

Some comments on the attached

Jo

On 26/06/2008 21:44, Francois Daoust wrote:
> 
> Hi,
> 
> The following comments apply to the treatment that a mobileOK checker 
> should apply to HTTP responses:
> http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/#http_response
> 
> * About the treatment of HTTP Status 401:
>   - Why should tests be applied to the response body of such an HTTP 
> response? The body will never be touched by any browser during the first 
> pass (when authentication credentials have not already been sent) 
> AFAICT. Besides, it wouldn't make any sense to display the resource if 
> it's an included image for instance. It's perfectly normal to count the 
> response in EXTERNAL_RESPONSE and PAGE_SIZE_LIMIT, but I suggest 
> updating the "Carry out tests on the response" to "Do not carry out 
> tests on the response", especially given the fact that the tests FAIL 
> when credentials are wrong (and so there's no need to test the response 
> body anyway even for the second pass)

 From HTTP

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a 
WWW-Authenticate header field (section 14.47) containing a challenge 
applicable to the requested resource. The client MAY repeat the request 
with a suitable Authorization header field (section 14.8). If the 
request already included Authorization credentials, then the 401 
response indicates that authorization has been refused for those 
credentials. If the 401 response contains the same challenge as the 
prior response, and the user agent has already attempted authentication 
at least once, then the user SHOULD be presented the entity that was 
given in the response, since that entity might include relevant 
diagnostic information. HTTP access authentication is explained in "HTTP 
Authentication: Basic and Digest Access Authentication" [43].

AFAIK, if I "cancel" on an authorization challenge then I get the 
content of the page displayed. Try it here:

http://rabin.mobi/tests/francois




>   - "Re-request the resource using authentication information" could 
> deserve some clarification. What if the checker doesn't have any 
> authentication information? I would clarify this with "Re-request the 
> resource using authentication information if available or FAIL" (where 
> FAIL would be HTTP_RESPONSE-7)

I don't disagree with this approach, but we have chosen to "remain 
silent" on what to do if there is no authentication information. Nor do 
we specify when and how such information is provided etc.
We do, however, note that

Implementations must support basic and digest authentication.

which implies that they have to have a mechanism for capturing it.

I don't object to the following clarification, but don't particularly 
see the need for it:

current text:

If authentication information was supplied in the HTTP request (i.e. 
authentication failed), FAIL

proposed text:

If authentication information was supplied in the HTTP request (i.e. 
authentication failed) or if none is available, FAIL





> 
> * HTTP responses and linked resources:
> I understand the LINK_TARGET_FORMAT test as willing to return WARNs to 
> the user on linked resources, and to never return any FAIL. However, 
> there are several cases in the tests that should be carried by the 
> checker for HTTP responses that return a FAIL, even when the resource is 
> a linked resource:
>   - "If an HTTP request does not result in a valid HTTP response [...], 
> FAIL"
>   - 1 case in "If the response is an HTTPS response"
>   - 2 cases in "If the HTTP status indicates redirection"
>   - "If the HTTP status represents failure (4xx), other than 404 or a 
> request for authentication (e.g. 401), FAIL"
> 
> I guess one may argue that LINK_TARGET_FORMAT may return a FAIL message. 
> The last point still stands in that case: is a linked resource that 
> returned a 406 Not Acceptable status supposed to trigger a FAIL? I think 
> I should be allowed to include links to external resources that are not 
> able to serve content to the mobileOK checker in a page without losing 
> the possibility for the page to be mobileOK. I would relax the last 
> check to state:
> "If the HTTP status represents failure (4xx), other than 404 or a 
> request for authentication (e.g. 401):
>   If the response relates to a request for a linked resource (see 2.4.7 
> Linked Resources), continue with the test (see 3.10 LINK_TARGET_FORMAT ) 
> and warn
>   Otherwise (i.e. for included resources), FAIL"

I could go with that one, makes sense for me.

I think it is also true that LINK_TARGET_FORMAT should return a FAIL in 
the remaining cases.

Mind you, I don't feel that so strongly that were Kai to threaten me in 
a full suit of armor wielding his mace in a threatening way, that I 
couldn't be persuaded, within a nano-second or two, to change my mind.

So I think that as Kai was principal defender of the "No FAIL on 
External Resources" principle you'd want to be sure he was cool with 
that. As well as checking with everyone else, too, of course, but not 
from such an urgent sense of personal safety.

Jo


> 
> Francois.
>

Received on Wednesday, 2 July 2008 14:02:01 UTC