W3C home > Mailing lists > Public > public-mobile-dev@w3.org > October 2010

Re: SVG on the move? validator bug report

From: Francois Daoust <fd@w3.org>
Date: Fri, 01 Oct 2010 11:35:46 +0200
Message-ID: <4CA5AB72.5080608@w3.org>
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:

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. ]]

That said, in a mobile context, using compression is a "good thing", and the mobileOK Checker should support common compression algorithms (gzip, deflate).

Received on Friday, 1 October 2010 09:36:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:09 UTC