W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: ByteString in Web IDL

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Jul 2013 00:56:45 -0400
Message-ID: <CA+c2ei-5T+YkfjWFNGgBsM3LRXbE878gxmM=o1XqNJhVNxA=ww@mail.gmail.com>
To: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>
On Wed, Jul 10, 2013 at 12:44 AM, Norbert Lindenberg
<ecmascript@lindenbergsoftware.com> wrote:
>
> On Jul 9, 2013, at 21:30 , Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Tue, Jul 9, 2013 at 11:58 PM, Norbert Lindenberg
>> <ecmascript@lindenbergsoftware.com> wrote:
>>> Why do Web IDL and XMLHttpRequest need ByteString [1, 2]? And why does ByteString have a conversion to/from ECMAScript strings that assumes ISO 8859-1 [3]?
>>>
>>> If I understand the previous discussion [4] correctly, XMLHttpRequest needs a way to communicate byte sequences that occur in HTTP status messages or headers for which HTTPbis doesn't specify a character encoding anymore, and for which XMLHttpRequest doesn't determine the character encoding either.
>>>
>>> For such byte sequences, ArrayBuffer or UInt8Array seem well suited, in particular since the proposed Encoding API [5, 6] uses them.
>>
>> It seems *very* annoying if you couldn't do
>>
>> xhr.open("GET", "/foo");
>> xhr.setResponseHeader("some-header", "value");
>> xhr.send();
>>
>> but instead had to do:
>>
>> xhr.open(new Int8Array([71, 69, 84]), "/foo");
>
> As I said in my email, using DOMString for the method (with appropriate error checking) would be fine.

That's exactly what ByteString is. ByteString is just a DOMString but
with error checking such that if any character is greater than 255 an
exception is thrown.

/ Jonas
Received on Wednesday, 10 July 2013 04:57:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC