- From: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
- Date: Tue, 9 Jul 2013 21:44:05 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>
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