- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 16 Jul 2013 11:57:19 -0400
- To: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
- Cc: Robin Berjon <robin@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Tue, Jul 16, 2013 at 2:12 AM, Norbert Lindenberg <ecmascript@lindenbergsoftware.com> wrote: > "Preserves the value space" is only half-true because the setters accepting ByteString reject all code points above U+00FF in the ECMAScript strings that are the real input. The value space of HTTP, doh. So it's totally true. >> Exposing the bytes works too of course, but given >> most byte sequences are "ASCII-compatible" that would be a bad API. > > What do you mean by "most byte sequences are ASCII-compatible", and why would that make actual bytes a bad API? Because byte sequences such as `Accept` and `X-Requested-With` etc. are much easier to write as strings. > Anyway, we don't need to design a new API here. Boris and Jonas have pointed out that the XMLHttpRequest API has to behave the way it does because it's a legacy API, and I accept that. What I'm asking for is that this legacy doesn't prejudice new APIs, that ByteString is removed from Web IDL, and that the legacy behavior is described entirely within the XMLHttpRequest spec. I would first like to see this "better API" before I agree that what we have for XMLHttpRequest is in fact not the way we want to deal with HTTP. This is not a hypothetical either, we're considering a new kind of API to interact with HTTP for http://fetch.spec.whatwg.org/ -- http://annevankesteren.nl/
Received on Tuesday, 16 July 2013 15:57:47 UTC