- From: Francois Daoust <fd@w3.org>
- Date: Fri, 01 Oct 2010 11:35:46 +0200
- To: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- CC: public-mobile-dev@w3.org
On 10/01/2010 10:03 AM, Francois Daoust wrote: [...] >> Not sure about this: >> >> The document is not valid UTF-8CHARACTER ENCODING SUPPORT > > Well, I'm not sure about this either. I created another bug entry and > will investigate: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10947 Investigation that lead to the creation of another bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10952 The mobileOK Checker does not support compressed content and just tries to parse the compressed content as HTML, which doesn't quite work, of course. It should at least return a warning that says that it does not support compressed content! Since the mobileOK Checker does not send any Accept-Encoding HTTP header field in the HTTP requests it sends to retrieve the page under test, I wondered whether the mobileOK Checker should rather return a failure that says "hey, you're using compression, whereas I didn't tell you that I support it". I had a look at the HTTP RFC. Although the wording is a bit convoluted, it does indeed advise against using content-coding unless the server knows that the client will support it: [[ If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client. ]] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3 That said, in a mobile context, using compression is a "good thing", and the mobileOK Checker should support common compression algorithms (gzip, deflate). Francois.
Received on Friday, 1 October 2010 09:36:42 UTC