W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2007

Re: please reivew mobileOK Basic Tests 1.0

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Sat, 29 Sep 2007 20:01:28 +0200
Message-ID: <46FE92F8.4070403@students.cs.uu.nl>
To: mike@w3.org
CC: public-bpwg-comments@w3.org
Hi,

Below are my comments to the resolution:

mike@w3.org schreef:
>  Dear Laurens Holst ,
>
> 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 (2nd Last Call) published on 25 May 2007. 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/TR/2007/WD-mobileOK-basic10-tests-20070928/.
>
> Please review it carefully and let us know if you agree with it or not
> before 19 October 2007. 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,
> Michael(tm) Smith
> W3C Staff Contact
>
>  1. http://www.w3.org/mid/4668801F.2090006@students.cs.uu.nl
>  2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/
>
>
> =====
>
> Your comment on 2.3.2 HTTP Request:
>   
>> First, section 2.3.2 HTTP Request states:
>>
>>     
>>>    *
>>>
>>>       Include an |Accept| header indicating that Internet media
>>>       
>> types
>>     
>>>       understood by the default delivery context are accepted by
>>>       sending exactly this header:
>>>
>>>       Accept:
>>>       
> application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
>   
>>>             
>>>
>>>       
>> I think this is incorrect, text/css should NOT be included in the
>> Accept 
>> header, and image/jpeg and image/gif ONLY if the UA is expected to 
>> support showing these images independantly of a document (the mobileOK
>>
>> tests should explicitly check whether this is supported). The client 
>> after all does not know how to handle a text/css file independently of
>>
>> XML markup.
>>
>> Instead, it should send an "Accept: text/css" header when the CSS files
>>
>> that are linked using <link rel="stylesheet">, <?xml-stylesheet?> or 
>> @include. Similarly, images referenced from <img> should send an 
>> "Accept: image/jpeg,image/gif" header. Aside from checking the Accept 
>> header for the main page, the mobileOK tests should also check that 
>> Accept headers send these values for stylesheet and image requests.
>>     
>
>
> Working Group Resolution:
> We do not think it is wrong to specify the headers in the way we do,
> however we accept that we do not properly check that the right sort of
> content has come back in response to the request. In other words, if the
> request is made because of an img tag then the response should be an
> image. We did not test for that in the draft you reviewed and we will
> amend accordingly. In particular, in 3.4, <img> tags that retrieve valid
> CSS delivered as text/css should for example FAIL too.
>   

I do not think this is the correct resolution (although it is good that 
the test now also checks the response).

The reason for this is that in your HTTP request you say that a file can 
be delivered in all the formats specified by the Accept header. Thus, if 
the server sends you a text/css file, it can not lead to FAIL because 
you asked for it.

Quote from the HTTP specification RFC 2616 section 14.1:

    The Accept request-header field can be used to specify certain media
    types which are acceptable for the response. Accept headers can be
    used to indicate that the request is specifically limited to a small
    set of desired types, as in the case of a request for an in-line
    image.
      


Checking in the UA (in this case, the test) for whether something is an 
image and throwing an error, but at the same time saying in the HTTP 
headers that you *do* accept non-images is inconsistent and incorrect. 
You are sending false information to the server. What’s worse, sites 
which *correctly* implement content negotiation properly and e.g. send 
text/css *according to the request*, will get a FAIL on your test.

The solution you propose breaks content negotiation as specified in RFC 
2616 and is not acceptable.
The solution I provide is to send the following HTTP header for requests 
resulting from <img> tags: Accept: image/jpeg,image/gif
An alternative solution is to not send an Accept header at all.

> ----
>
> Your comment on 2.3.2 HTTP Request:
>   
>> Third, in that same section, there is a requirement that only HTTP GET 
>> methods can only be used. What about form submissions with POST?
>> Forcing 
>> forms to be sent with the GET method seems undesirable and impairs the
>>
>> HTTP functionality. It seems a silly limitation too, because if a 
>> mobileOK Basic application must support HTTP and HTTPS, and Basic and 
>> Digest HTTP authentication, then surely support for POST would be 
>> trivial. The mobileOK tests should provide tests for checking proper 
>> cache clearing after a POST request has been done on a URL.
>>     
>
>
> Working Group Resolution:
> We will insert a reference in 2.3.2 referring to 2.3.8 to make it clearer
> that POST is definitely allowed as a form action in mobileOK content but
> that it is simply not tested, for fear of the tester causing unwanted side
> effects.
>   

Great.

> ----
>
> Your comment on 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP:
>   
>> Fifth, in 3.4 CONTENT_FORMAT_SUPPORT  and VALID_MARKUP it does not 
>> distinguish included resources by type, that is, if it’s a stylesheet
>>
>> include, only the text/css media type should be accepted (otherwise 
>> FAIL), and if it’s an image include, only image/gif or image/jpeg is
>>
>> accepted and not text/css. If it’s an object include, unless the UA
>> is 
>> expected to support CSS there by showing it somehow, text/css should 
>> also not be accepted.
>>     
>
>
> Working Group Resolution:
> We will add that if the resource is expected to be a stylesheet, it must
> be text/css (and be valid CSS), and likewise for images and FAIL if it is
> not - also that Objects need to be images in this case.
>   

Great.


Regards,

~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.



Received on Saturday, 29 September 2007 18:01:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 June 2012 12:13:31 GMT