I think HeaderMap is a good idea (if nothing else, because it's clearly not a
map, but instead a multimap).
That said, in terms of what is accepted, it would make sense to define
conversion algorithms for both iterables-of-key-value-pairs (the duck-type
version of Maps) and, for convenience in the 80% case, object literals.
Expressing the semantics in JS (which, as always, is a better way of doing
things than WebIDL or prose):
```js
function acceptsHeaderMapish(thing) {
const headerMap = new HeaderMap();
if (thing instanceof HeaderMap /* or more specific brand check */) {
headerMap = thing;
} else {
const iterator = thing[Symbol.iterator];
if (iterator) {
for (let [key, value] of iterator) {
headerMap.add(key, value);
}
} else if (typeof thing === "object") {
for (let key of Object.keys(thing)) {
headerMap.add(key, thing[key]);
}
} else {
throw new TypeError("Must pass an iterable or an object when a
header-map-like is expected");
}
}
// can use headerMap now
}
```
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Anne van Kesteren
Sent: Friday, June 6, 2014 17:31
To: Jonas Sicking
Cc: Domenic Denicola; public-script-coord; Joshua Bell; Jungkee Song; Yehuda
Katz; Alex Russell; Jake Archibald; Tobie Langel; WebApps WG
Subject: Re: Fetch API
On Fri, Jun 6, 2014 at 10:26 AM, Jonas Sicking <[email protected]> wrote:
> I'm still arguing that we shouldn't have a HeaderMap class at all, and
> instead just use normal Map objects. And in places where we take a map
> as an argument, also allow plain JS objects that are then enumerated.
You have not explained how that would work however. Adding headers might have
to change the mode of the request. We cannot allow all headers. A Map does not
even map to how HTTP headers work. As discussed in
https://github.com/slightlyoff/ServiceWorker/issues/300
headers are a list where you can have duplicate names and ordering is sometimes
significant.
--
http://annevankesteren.nl/
