Re: SVG on the move? validator bug report

Francois,

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.
http://www.w3.org/2003/01/xhtml-mimetype/content-negotiation

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

best

Jonathan

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