[webkit-dev] XHR responseArrayBuffer attribute

[James Robinson]

On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren <
annevankesteren at gmail.com> wrote:

> (I'm subscribed to webkit-dev with a different address.)
>
> On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman <michaeln at google.com>
> 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 public-webapps at w3.org.
>
> Cheers,
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100927/b0271a5e/attachment.html>