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

Re: SVG on the move? validator bug report

From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
Date: Fri, 1 Oct 2010 10:50:43 +0100
To: Francois Daoust <fd@w3.org>
Message-Id: <77117C7C-AF29-44E0-BF5F-0BF3AB41AEC1@btinternet.com>
Cc: public-mobile-dev@w3.org

I've also been investigating how to set my server up to serve mime  
type text/html where accept header indicates svg is not supported.

however the best resource I found (from 2003) states:

Can I serve one resource with two distinct MIME-types?
While it's theoretically possible, I don't know any way to do it  
without breaking some important aspects of HTTP (such as proxying, or  
the HTTP PUT method) - that is, the method I know using RewriteRules  
doesn't set headers such as ETag as it should.

wonder if Dom@w3.org could improve on this today?



On 1 Oct 2010, at 10:35, Francois Daoust wrote:

> 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 10:17:23 UTC

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