W3C home > Mailing lists > Public > public-webapi@w3.org > July 2007

Re: [XHR2] overrideMimeType

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 28 Jul 2007 23:23:21 -0700
Cc: Anne van Kesteren <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <49BDADA9-C203-4F10-953C-FC7218426140@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Jul 27, 2007, at 12:09 PM, Jonas Sicking wrote:

> Anne van Kesteren wrote:
>> I've been looking at overrideMimeType implementations in Gecko and  
>> WebKit and it seems like they differ a bit. In Gecko it has to be  
>> invoked before send(), but in WebKit it would work if you invoke it  
>> just before getting responseXML or responseText. Neither  
>> implementation seems to do any input checks.
>> If you have any opinion on how it should be specified I suppose now  
>> would be the time to air your thoughts.
> Of course I prefer the mozilla way :)
> It does seem fairly complicated to allow it to be set after the  
> download is finished though. You do have the stream stored  
> in .reponseBody, but at that point all encoding information has been  
> lost. For HTML parsing (which I hope the spec will support in the  
> future) there are a pile of rules used to guess the encoding, all of  
> which would be useful to use, but can't be used if all you have  
> access to is the unencoded responseBody.

Why would the encoding information be lost? The only sources of  
encoding info are the responseText itself and http headers, both of  
which the XMLHttpResponse needs to provide anyway.

If possible I'd rather have the spec take the more permissive  
approach, since we might have some WebKit-specific content (like  
Dashboard widgets) depending on late setting of the overrideMimeType.  
And it's somewhat less likely for content to depend on late setting  
not working (the usual use is to set an XML MIME type to be able to  
access responseXML).

Received on Sunday, 29 July 2007 06:24:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC