On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren < [email protected]> wrote:
> (I'm subscribed to webkit-dev with a different address.) > > On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman <[email protected]> > wrote: > > Yes, if we go with telling xhr up front for the array buffer case, I > guess > > an enum would be slightly better. > > I do not think this should be told up front. You already need to keep > the octet buffer in memory for overrideMimeType to work the way it > does. We designed responseBlob as an optimization so you would not > have to deal with the other types. I do not think you can optimize the > reverse with the design as it stands today. > I see the source of confusion. I take it that your reading of http://www.w3.org/TR/XMLHttpRequest2/#the-overridemimetype-method is that if the mime type is ever overriden and there is a subsequent access of .responseText, the response body must be re-decoded with the encoding specified by the new mimetype. WebKit does not implement this functionality - the response text decoder is initialized when the first byte is received from the network based on the override mime type (if present) and response encoding at that time. The decoding behavior from this point on does not change. WebKit does not save the raw bytes off the network between receiving chunks of data from the network, instead it decodes chunks as they arrive and saves them as UTF16 strings. Frankly, being able to arbitrarily change the encoding at any point and time and ask for the responseText using a different encoding sounds dumb - but I'm guessing you will say that is a debate for public-webapps@ - James > > In any event, any discussion on changes to the specification really > ought to happen on [email protected]. > > Cheers, > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
