List Info

Thread: Re: please reivew mobileOK Basic Tests 1.0




Re: please reivew mobileOK Basic Tests 1.0
country flaguser name
Netherlands
2007-09-29 13:01:28
Hi,

Below are my comments to the resolution:

w3.org">mikew3.org schreef:
wiggum.w3.org" type="cite">
 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. students.cs.uu.nl">http://www.w3.org/mid/4668801F.2090006students.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?&gt; 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.

wiggum.w3.org" type="cite">
----

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.

wiggum.w3.org" type="cite">
----

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.
  
RE: please reivew mobileOK Basic Tests 1.0
country flaguser name
Ireland
2007-09-30 04:41:59

Laurens

 

Thanks for your further reply on this. Ref RFC2616

 

Accept headers can be used to specify certain media

types which are acceptable for the response. …

 

Not “should or “must”.

 

And if the server needs to respond with a 3xx, 4xx or 5xx response code, in principle it would not know how to do that if the request did not contain a range of content types.

 

Jo

 


From: public-bpwg-comments-requestw3.org [mailto:public-bpwg-comments-requestw3.org] On Behalf Of Laurens Holst
Sent: 29 September 2007 19:01
To: mikew3.org
Cc: public-bpwg-commentsw3.org
Subject: Re: please reivew mobileOK Basic Tests 1.0

 

Hi,

Below are my comments to the resolution:

mikew3.org">mikew3.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. students.cs.uu.nl">http://www.w3.org/mid/4668801F.2090006students.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&quot; header when the CSS files
 
that are linked using <link rel="stylesheet&quot;>, <?xml-stylesheet?&gt; or 
include. Similarly, images referenced from <img>; should send an 
"Accept: image/jpeg,image/gif&quot; 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.
Re: Re: please reivew mobileOK Basic Tests 1.0 ( LC-1859)
country flaguser name
United States
2007-10-25 06:38:43

 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 (Third Last Call) published on 28 Sep 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.

Please review it carefully and let us know by email at
public-bpwg-commentsw3.org if you agree with it or not before
31 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/46FE92F8.4070403students.cs.uu.nl
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070928/


=====

Your comment on 2.4.2 HTTP Request:
> Jo Rabin schreef:
> >
> > Laurens
> >
> >
> >
> > Thanks for your further reply on this. Ref
RFC2616
> >
> >
> >
> > Accept headers *can* be used to specify certain
media
> >
> > types which are acceptable for the response. …
> >
> >
> >
> > Not “should” or “must”.
> >
> 
> I think you’re misinterpreting that sentence, it
“can” be used
> because
> the Accept header is optional. It does not imply the
Accept header can
> be used differently than described, and that you can
just put any kind
> of nonsense in there and still expect it to work.
> 
> > And if the server needs to respond with a 3xx, 4xx
or 5xx response
> > code, in principle it would not know how to do
that if the request
> did
> > not contain a range of content types.
> >
> 
> I don’t understand how that would be. Different
content types are
> just
> different representations of data. A single resource
can be
> represented
> by several content types. If you’re going to indicate
to the server
> that
> you accept certain representations, then the server can
send any of
> them. However regardless of the content type, the
server knows
> perfectly
> well when a response of 3xx, 4xx or 5xx is needed for
that resource
> (e.g. when it has moved or is unavailable). They’re
two separate
> things,
> and unrelated.
> 
> I do not understand the resistance against just sending
the correct
> Accept headers. That is how the protocol is designed,
and it’s also
> how
> browsers implement it.
> 
> Also, you’re completely glossing over my statement
that sending
> incorrect Accept headers *breaks* servers which
correctly handle
> content
> negotiation, because the accepted content types are not
correctly
> indicated by the test. Thus, with this test the W3C
would force web
> sites to not use content negotiation if they want to
get your label
> for
> ‘correctness’.


Working Group Resolution (LC-1859):
Behavior as specified does not
contravene HTTP. In practice, it is consistent with most
mobile UAs
behavior and is desirable on practical grounds for a tester
to emulate.
It should not be inferred from the way the checker behaves
that real
browsers either should or should not behave that way.

----




[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )