W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Fetch API

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 01 Jun 2014 14:13:35 -0400
Message-ID: <538B6D4F.8000001@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>, Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>, Joshua Bell <jsbell@chromium.org>, Jungkee Song <jungkee.song@samsung.com>, Yehuda Katz <wycats@gmail.com>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>, Jake Archibald <jaffathecake@gmail.com>, Tobie Langel <tobie.langel@gmail.com>
CC: WebApps WG <public-webapps@w3.org>
On 6/1/14, 2:06 AM, Domenic Denicola wrote:
> - Named constructors scare me (I can't figure out how to make them work in JavaScript without breaking at least one of the normal invariants). I think a static factory method would make more sense for RedirectResponse.

Or just a constructor overload, if the type of "body" for the existing 
constructor can be told apart from a string.  Which may not be the case, 
of course.

> - HeaderMap should have a constructor that takes an iterable of [key, value] pairs, in the same way Map does.

So a sequence<sequence<ByteString>> basically, right?  Seems pretty 
plausible to me.

> - I like HeaderMap a lot, but for construction purposes, I wonder if a shorthand for the usual case could be provided. E.g. it would be nice to be able to do
> fetch("http://example.com", {
>    headers: {
>      "X-Foo": "Bar"

We've had other cases arise where such an "open-ended dictionary" 
construct would be useful.  The only difference is that those other 
cases wanted string-valued keys while this might want ByteString-valued 

One concern here: is order an issue for headers?  I seem to vaguely 
recall that in practice order can matter with some HTTP servers.


P.S.  Still reading through; will have feedback of my own in the next 
few days.
Received on Sunday, 1 June 2014 18:14:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC