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

Re: ByteString in Web IDL

From: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
Date: Tue, 9 Jul 2013 21:44:05 -0700
Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>
Message-Id: <C297EE78-4C80-4D17-8B56-FD4B88AF6C66@lindenbergsoftware.com>
To: Jonas Sicking <jonas@sicking.cc>

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.

> xhr.setResponseHeader(Int8Array([115, 111, 109, 101, 45, 104...]),
> Int8Array([...]));

Same for the header name. That leaves the header value, but that issue should be solved in the XMLHttpRequest spec, not through a new type in Web IDL.

Norbert
Received on Wednesday, 10 July 2013 04:44:31 UTC

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