Re: Clarifications on HTTP Response tests ( LC-1991 LC-1992)

 Dear Francois Daoust ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 (Fourth Last Call) published on 10 Jun 2008. Thank you for
having taken the time to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r.

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 5 August
2008. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://www.w3.org/mid/4863FF93.7080002@w3.org
 2. http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/


=====

Your comment on 2.4.3 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)
>    - "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)
> 


Working Group Resolution (LC-1991):
On your first point, we think that the tests should be carried on the
response body because, as specified in the HTTP (RFC 2616) section 10.4.2
401 Unauthorized, the body of the HTTP Status 401 response should be
presented to the user if the authentication fails:
 "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"

On your second point, we think that the text deserved to be clarified and
updated the relevant part to state:
 "If authentication information was supplied in the HTTP request (i.e.
authentication failed) or if no authentication information is available,
FAIL"

See:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response

----

Your comment on 2.4.3 HTTP Response:
> * 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"


Working Group Resolution (LC-1992):
Links in a Web page intended for mobile consumption are an important
constituent of the user experience. The user should be able to "trust"
that clicking on a link does not yield an error message.

For that reason, we think that returning FAILs in the LINK_TARGET_FORMAT
is indeed needed.

However, it occurred to us that HTTP Status 406 responses could well be
returned for resources tasted by section 3.15.1 Object Element Processing
Rule, and that this should obviously not trigger a FAIL, so we relaxed
that last condition in that case as you suggested:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response

----

Received on Thursday, 31 July 2008 13:15:30 UTC