Re: Fetch API
On Mon, Jun 9, 2014 at 8:52 PM, Ali Alabbas wrote:
> We (MS) reviewed the Fetch API and had the following questions/notes from our
> discussion:
Awesome, thanks!
> Is there an algorithm (such as SCA) that will be used to serialize these
> objects so that they may be persisted in the Cache?
Yes, we need to define how they can be structured cloned. I haven't
gotten around to it yet. Mostly been working on the basics. The main
problem with structured clones will be figuring out how that should
work with streams.
> 2. Is there a scenario where we would want to have a Request inside of a
> Request? It appears that one could construct a Request and pass in a
> RequestInfo as input which is defined as either a Request or
> ScalarValueString.
It simply copies at that point. There's no nesting or pointers involved.
> * One could do this:
>
> var request1 = new Request("http://www.example.com/";);
> var request2 = new Request(request1);
> var request3 = new Request(request2);
> fetch(request3);
Yeah, this works through copying the data. No pointers.
> 3. Are there scenarios where once you set the Request url, we would change it
> before fetching? If not, the url could be readonly. Otherwise, it could be
> optional in the constructor as it could always be defined later.
We have changed members to be readonly for now. We can later consider
opening that up a bit, but that requires very careful reasoning on the
effects.
> 4. Are we expecting to build XML content types using the “text” body type? It
> would be nice if we directly supported “xml” and included them in the
> FetchBodyType enum.
You mean for XML documents? I suppose we could offer XML and HTML
features in due course. My idea was to grow the API slowly. See what
web developers build with it first and then add the low hanging fruit.
There's already a ton for implementers to do.
> 5. Also, are we considering support for "streams" as another type in the
> FetchBodyType?
The current idea is that .body will eventually return an actual
stream. For now it returns an object that exposes a to() method. That
to() method basically reads until the end of the stream and converts
the data. Once we get actual JavaScript IO streams we can refactor
this object with a to() method to be a subclass of such an IO stream.
I'm coordinating with Domenic who is working on JavaScript IO streams
to make sure this all works.
--
http://annevankesteren.nl/
RE: Fetch API
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: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] 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 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/
Re: Fetch API
On Fri, Jun 6, 2014 at 10:26 AM, Jonas Sicking 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/
Re: Fetch API
On Fri, Jun 6, 2014 at 12:33 AM, Domenic Denicola wrote: > It seems to me that for both the HeaderMap constructor and any object-literal > processing, the best solution for now is to just do things in prose... I think the first thing we should decide on is what syntax we want JS authors to be able to write. How to then write this in the spec can be debated after. The capability set of WebIDL should not dictate how we define the API (other than that we should be very sure about what we're doing if we go outside of what WebIDL recommends). 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. / Jonas
Re: Fetch API
On Fri, Jun 6, 2014 at 9:33 AM, Domenic Denicola wrote: > It seems to me that for both the HeaderMap constructor and any object-literal > processing, the best solution for now is to just do things in prose... I don't think that scales. There's quite a few APIs that want this. Keeping hem all compatible would be a nightmare. We need common idioms. -- http://annevankesteren.nl/
RE: Fetch API
For those who were not subscribed to public-webapps when that thread went down, here is the most convincing message: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0150.html I was previously in favor of keeping things simpler by just doing ArrayBuffer, as it feels more right to have APIs accept the “underlying buffer” instead of “just a view,” but that message changed my mind by giving a practical argument why that is not tenable. From: Takeshi Yoshino [mailto:tyosh...@google.com] Sent: Wednesday, June 4, 2014 15:31 To: Anne van Kesteren Cc: public-script-coord; Joshua Bell; Jungkee Song; Yehuda Katz; Alex Russell; Jonas Sicking; Jake Archibald; Tobie Langel; WebApps WG Subject: Re: Fetch API For XHR.send(), we've finally chosen to accept only ArrayBufferView. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0141.html Do we want to do the same for FetchBody body of RequestInit?
RE: Fetch API
It seems to me that for both the HeaderMap constructor and any object-literal
processing, the best solution for now is to just do things in prose...
-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
Sent: Wednesday, June 4, 2014 00:50
To: Domenic Denicola
Cc: public-script-coord; Joshua Bell; Jungkee Song; Yehuda Katz; Alex Russell;
Jonas Sicking; Jake Archibald; Tobie Langel; WebApps WG
Subject: Re: Fetch API
On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
wrote:
> - HeaderMap should have a constructor that takes an iterable of [key, value]
> pairs, in the same way Map does.
Yeah, waiting for IDL hooks that would work here ;-)
> - 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"
> }
> });
>
> instead of, assuming a constructor is added,
>
> fetch("http://example.com";, {
> headers: new HeaderMap([
> ["X-Foo", "Bar"]
> ])
> });
Yeah, it's not clear to me what is best here. An object whose keys are
ByteString and values are either ByteString or a sequence of ByteString? I
agree that we want this. Part of the problem here is how to best represent HTTP
headers. See
https://github.com/slightlyoff/ServiceWorker/issues/300 for more details.
--
http://annevankesteren.nl/
Re: Fetch API
On Wed, Jun 4, 2014 at 2:46 AM, Anne van Kesteren wrote:
> On Wed, Jun 4, 2014 at 9:49 AM, Jonas Sicking wrote:
>> On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren wrote:
>>> Does ES define the order of { "x": "a", "y": "b" } btw?
>>
>> I believe so, but someone would need to check. Either way I think
>> browsers effectively are forced to return a consistent order for
>> web-compat reasons.
>
> I checked. It's not true, see
> http://esdiscuss.org/topic/for-in-evaluation-order#content-10
Ah. So the enumeration order for { "x": "a", "y": "b" } is actually
consistent across browsers. But once you start doing more complex
things than that, like sticking enumerable properties on the prototype
chain, or deleting properties, then the order is not consistent.
I would still be ok with allowing a plain JS object being passed. If
differences in order for "complex" operations hasn't bitten people for
JS enumeration, then maybe it won't for header order either.
/ Jonas
Re: Fetch API
On Wed, Jun 4, 2014 at 9:49 AM, Jonas Sicking wrote:
> On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren wrote:
>> Does ES define the order of { "x": "a", "y": "b" } btw?
>
> I believe so, but someone would need to check. Either way I think
> browsers effectively are forced to return a consistent order for
> web-compat reasons.
I checked. It's not true, see
http://esdiscuss.org/topic/for-in-evaluation-order#content-10 See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ordinary-object-internal-methods-and-internal-slots-enumerate
for the specification. It seems in particular implementations will
differ on numeric "keys", potentially other bits.
--
http://annevankesteren.nl/
Re: Fetch API
On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren wrote:
> Does ES define the order of { "x": "a", "y": "b" } btw?
I believe so, but someone would need to check. Either way I think
browsers effectively are forced to return a consistent order for
web-compat reasons.
/ Jonas
Re: Fetch API
On Tue, Jun 3, 2014 at 9:00 PM, Jonas Sicking wrote:
> One thing we should keep in mind is if we actually need to support
> 100% of all the crazyness that servers do. And especially if we need
> to support it in a particularly convenient way.
Yes, that is https://github.com/slightlyoff/ServiceWorker/issues/300
Feedback would be greatly appreciated. Given Mark's latest comment
there it seems the current API might be broken.
Does ES define the order of { "x": "a", "y": "b" } btw?
--
http://annevankesteren.nl/
Re: Fetch API
On Wed, Jun 4, 2014 at 8:30 AM, Takeshi Yoshino wrote: > For XHR.send(), we've finally chosen to accept only ArrayBufferView. > http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0141.html > > Do we want to do the same for FetchBody body of RequestInit? What I really want is for IDL to be fixed as technically we cannot mention ArrayBuffer and ArrayBufferView in IDL as they are not IDL-defined constructs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369 I'd like something in IDL where I can just say "this accepts bytes" and "I want to return bytes", and IDL handles the complexities and ensures all APIs are compatible on this. What we did for XMLHttpRequest was probably a mistake as we could not make it an overarching policy. -- http://annevankesteren.nl/
Re: Fetch API
On Wed, Jun 4, 2014 at 8:13 AM, Takeshi Yoshino wrote: > On Mon, Jun 2, 2014 at 6:59 PM, Anne van Kesteren wrote: >> That's an internal algorithm never directly used. You can only get >> there from http://fetch.spec.whatwg.org/#concept-fetch and that can >> only be reached through an API such as fetch(). > > Right. But preflight's client and context are not initialized before > invoking HTTP fetch (http://fetch.spec.whatwg.org/#concept-http-fetch). > client is referred in HTTP fetch. Thanks! And my apologies for not getting that straight away. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25971 > BTW, "handle a fetch" is a dead link. > https://slightlyoff.github.io/ServiceWorker/spec/service_worker/handle-a-fetch Fixed. -- http://annevankesteren.nl/
Re: Fetch API
For XHR.send(), we've finally chosen to accept only ArrayBufferView. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0141.html Do we want to do the same for FetchBody body of RequestInit?
Re: Fetch API
On Mon, Jun 2, 2014 at 6:59 PM, Anne van Kesteren wrote: > On Thu, May 29, 2014 at 4:25 PM, Takeshi Yoshino > wrote: > > http://fetch.spec.whatwg.org/#dom-request > > Add steps to set client and context? > > That happens as part of the "restricted copy". However, that might > still change around a bit. Ah, ok. > > http://fetch.spec.whatwg.org/#cors-preflight-fetch-0 > > Add steps to set client and context? > > That's an internal algorithm never directly used. You can only get > there from http://fetch.spec.whatwg.org/#concept-fetch and that can > only be reached through an API such as fetch(). Right. But preflight's client and context are not initialized before invoking HTTP fetch (http://fetch.spec.whatwg.org/#concept-http-fetch). client is referred in HTTP fetch. BTW, "handle a fetch" is a dead link. https://slightlyoff.github.io/ServiceWorker/spec/service_worker/handle-a-fetch > > The promise is rejected with a TypeError which seems inconsistent with > XHR. > > Is this intentional? > > Yes. I wanted to stick to JavaScript exceptions. However, I suspect at > some point once we have FormData integration and such there might be > quite a bit of dependencies on DOM in general, so maybe that is moot. > Got it. Thanks.
Re: Fetch API
On Tue, Jun 3, 2014 at 9:38 AM, Jake Archibald wrote:
> On 3 June 2014 16:50, Anne van Kesteren wrote:
>>
>> On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
>> wrote:
>>
>> > - 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"
>> > }
>> > });
>> >
>> > instead of, assuming a constructor is added,
>> >
>> > fetch("http://example.com";, {
>> > headers: new HeaderMap([
>> > ["X-Foo", "Bar"]
>> > ])
>> > });
>>
>> Yeah, it's not clear to me what is best here. An object whose keys are
>> ByteString and values are either ByteString or a sequence of
>> ByteString? I agree that we want this.
>
> I vote ByteString: ByteString. If you want something more complicated,
> provide a HeaderMap or mutate after construction.
One thing we should keep in mind is if we actually need to support
100% of all the crazyness that servers do. And especially if we need
to support it in a particularly convenient way.
Something like
headers: {
"X-Foo": "Bar"
}
Does actually have a defined order between the name-value pairs, even
though it's not terribly explicit. And we could even support
headers: {
"X-Foo": ["Bar", "Bar2"]
}
For supporting sending multiple "X-Foo" headers.
This wouldn't support interleaving headers such that we send two
"X-Foo" headers with a "X-Bar" header in between, but are there
actually use cases for that?
I feel fairly sure that simply doing:
headers: {
"X-Foo": ["Bar", "Bar2"]
}
Will cover well over 99% of everything that people need to do. And
hopefully the remaining part of a percent could update their servers
to actually support HTTP semantics properly.
/ Jonas
Re: Fetch API
On 3 June 2014 16:50, Anne van Kesteren wrote:
> On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
> wrote:
>
> - 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"
> > }
> > });
> >
> > instead of, assuming a constructor is added,
> >
> > fetch("http://example.com";, {
> > headers: new HeaderMap([
> > ["X-Foo", "Bar"]
> > ])
> > });
>
> Yeah, it's not clear to me what is best here. An object whose keys are
> ByteString and values are either ByteString or a sequence of
> ByteString? I agree that we want this.
I vote ByteString: ByteString. If you want something more complicated,
provide a HeaderMap or mutate after construction.
Re: Fetch API
On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
wrote:
> - HeaderMap should have a constructor that takes an iterable of [key, value]
> pairs, in the same way Map does.
Yeah, waiting for IDL hooks that would work here ;-)
> - 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"
> }
> });
>
> instead of, assuming a constructor is added,
>
> fetch("http://example.com";, {
> headers: new HeaderMap([
> ["X-Foo", "Bar"]
> ])
> });
Yeah, it's not clear to me what is best here. An object whose keys are
ByteString and values are either ByteString or a sequence of
ByteString? I agree that we want this. Part of the problem here is how
to best represent HTTP headers. See
https://github.com/slightlyoff/ServiceWorker/issues/300 for more
details.
--
http://annevankesteren.nl/
Re: Fetch API
On Tue, Jun 3, 2014 at 3:04 PM, Domenic Denicola wrote: >> Agreed. So Response.redirect(url, status)? > > LGTM Done. -- http://annevankesteren.nl/
Re: Fetch API
On Thu, May 29, 2014 at 4:58 PM, Marcos wrote:
> I would change them to:
> enum RequestMode { "same-origin", "cors", "cors-tainted", "cors-preflight" };
cors-preflight does not really express the same thing. "cors" might
have preflights too. But maybe I should hide the difference between
CORS and CORS-with-forced-preflight at the API level.
>> enum RequestOmitCredentialsMode { "always", "CORS", "never" };
>
> The item "CORS" here is not self evident (unlike "always"/"never" modes). Can
> you find a better word?
Jake came up with same-origin which works if you rename omit
credentials mode to credentials mode and flip the other values as
well. That's implemented now.
--
http://annevankesteren.nl/
Re: Fetch API
Ugh, I meant "Request" for a lot of that: I'd like to add similar-style factories to *Request* which set header & mode defaults Request.image(url); Request.font(url); etc. Don't need these for the first pass though. On 3 June 2014 14:01, Jake Archibald wrote: > On 2 June 2014 00:08, Domenic Denicola > wrote: >> >> > Presumably RedirectResponse being a subtype would also be acceptable, >> as its .prototype.constructor would be RedirectResponse? >> >> Yeah, although I'm not sure there's a need to override any functionality >> here, so not sure that there's a need for subclassing. >> > > Agreed. So Response.redirect(url, status)? > > Btw, I'd like to add similar-style factories to Response which set header > & mode defaults > > Response.image(url); > Response.font(url); > > etc. Don't need these for the first pass though. > >
RE: Fetch API
From: Jake Archibald [mailto:jaffathec...@gmail.com] > Agreed. So Response.redirect(url, status)? LGTM
Re: Fetch API
On 2 June 2014 00:08, Domenic Denicola wrote: > > > Presumably RedirectResponse being a subtype would also be acceptable, as > its .prototype.constructor would be RedirectResponse? > > Yeah, although I'm not sure there's a need to override any functionality > here, so not sure that there's a need for subclassing. > Agreed. So Response.redirect(url, status)? Btw, I'd like to add similar-style factories to Response which set header & mode defaults Response.image(url); Response.font(url); etc. Don't need these for the first pass though.
Re: Fetch API
On Thu, May 29, 2014 at 4:25 PM, Takeshi Yoshino wrote: > http://fetch.spec.whatwg.org/#dom-request > Add steps to set client and context? That happens as part of the "restricted copy". However, that might still change around a bit. > http://fetch.spec.whatwg.org/#cors-preflight-fetch-0 > Add steps to set client and context? That's an internal algorithm never directly used. You can only get there from http://fetch.spec.whatwg.org/#concept-fetch and that can only be reached through an API such as fetch(). > http://fetch.spec.whatwg.org/#concept-legacy-fetch > http://fetch.spec.whatwg.org/#concept-legacy-potentially-cors-enabled-fetch > Steps to set url, client and context are missing here too. But not worth > updating this section anymore? Yeah. I need to work with Ian at some point to rework HTML. > Termination reason is not handled intentionally (only supposed to be used by > XHR's functionalities and nothing would be introduced for Fetch API?)? It's a bit unclear yet how we are supposed to deal with that. > The promise is rejected with a TypeError which seems inconsistent with XHR. > Is this intentional? Yes. I wanted to stick to JavaScript exceptions. However, I suspect at some point once we have FormData integration and such there might be quite a bit of dependencies on DOM in general, so maybe that is moot. -- http://annevankesteren.nl/
RE: Fetch API
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] > Out of curiosity, would you be okay with it if it was just an override? That > is, if "new Response(...)" took either set of arguments for the ... part? It > sounds like you would be. Yeah, I mean, I think in this case it would be kind of awkward for clarity, but from a JS language perspective it's perfectly fine. > This is identically a problem with the case I gave, as > Bar.prototype.constructor would be Foo, not Bar. It's possible that this is > still a problem, it's just not unique to named constructors. ^_^ Since `Foo === Bar` in your case, it's not really a problem. > Since you suggested a static method, that suggests you're fine with Response.Redirect(http://example.com) giving a new Response object, right? It's just the fact that RedirectResponse has a .prototype pointing to Response.prototype that gives you pause? Yeah exactly. (Although it should be lowercase since it's a factory, not a constructor.) > Presumably RedirectResponse being a subtype would also be acceptable, as its > .prototype.constructor would be RedirectResponse? Yeah, although I'm not sure there's a need to override any functionality here, so not sure that there's a need for subclassing.
Re: Fetch API
On Sun, Jun 1, 2014 at 2:19 PM, Domenic Denicola
wrote:
> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
>> Using NamedConstructor is identical to doing:
>>
>> ```js
>> class Foo { ... }
>> let Bar = Foo;
>> // now I can do "new Foo()" or "new Bar()", to the same effect.
>> ```
>
> Not true, since the constructors take different arguments.
Ah right, I forgot that the arguments are different. This effectively
makes it a constructor with overrides, where the function you call it
with is taken as one of the arguments used for discriminating between
overrides.
Out of curiosity, would you be okay with it if it was just an
override? That is, if "new Response(...)" took either set of
arguments for the ... part? It sounds like you would be.
> Instead it is equivalent to
>
> ```js
> class Response {
> constructor(body, init) { ... }
> ...
> }
>
> function RedirectResponse(url, status = 302) {
> return new Response(???, ???);
> }
> RedirectResponse.prototype = Response.prototype;
> ```
>
>> What invariants are you concerned about?
>
> In particular, we have that
>
> ```js
> RedirectResponse.prototype.constructor !== RedirectResponse
> (new RedirectResponse(...)).constructor !== RedirectResponse
> // Also, omitting the `new` does not throw a `TypeError`, like it does for
> real constructors.
> ```
>
> and possibly a few others I am forgetting.
This is identically a problem with the case I gave, as
Bar.prototype.constructor would be Foo, not Bar. It's possible that
this is still a problem, it's just not unique to named constructors.
^_^
Since you suggested a static method, that suggests you're fine with
Response.Redirect(http://example.com) giving a new Response object,
right? It's just the fact that RedirectResponse has a .prototype
pointing to Response.prototype that gives you pause?
Presumably RedirectResponse being a subtype would also be acceptable,
as its .prototype.constructor would be RedirectResponse?
~TJ
RE: Fetch API
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
> Using NamedConstructor is identical to doing:
>
> ```js
> class Foo { ... }
> let Bar = Foo;
> // now I can do "new Foo()" or "new Bar()", to the same effect.
> ```
Not true, since the constructors take different arguments. Instead it is
equivalent to
```js
class Response {
constructor(body, init) { ... }
...
}
function RedirectResponse(url, status = 302) {
return new Response(???, ???);
}
RedirectResponse.prototype = Response.prototype;
```
> What invariants are you concerned about?
In particular, we have that
```js
RedirectResponse.prototype.constructor !== RedirectResponse
(new RedirectResponse(...)).constructor !== RedirectResponse
// Also, omitting the `new` does not throw a `TypeError`, like it does for real
constructors.
```
and possibly a few others I am forgetting.
Re: Fetch API
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> 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
ones...
One concern here: is order an issue for headers? I seem to vaguely
recall that in practice order can matter with some HTTP servers.
-Boris
P.S. Still reading through; will have feedback of my own in the next
few days.
Re: Fetch API
On Sat, May 31, 2014 at 11:06 PM, 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.
What invariants are you concerned about? Using NamedConstructor is
identical to doing:
```js
class Foo { ... }
let Bar = Foo;
// now I can do "new Foo()" or "new Bar()", to the same effect.
```
~TJ
RE: Fetch API
Overall it looks really solid. Only a few things I could think of:
- 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.
- HeaderMap should have a constructor that takes an iterable of [key, value]
pairs, in the same way Map does.
- 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"
}
});
instead of, assuming a constructor is added,
fetch("http://example.com";, {
headers: new HeaderMap([
["X-Foo", "Bar"]
])
});
-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
Sent: Thursday, May 29, 2014 08:57
To: public-script-coord; Joshua Bell; Jungkee Song; Yehuda Katz; Alex Russell;
Jonas Sicking; Jake Archibald; Tobie Langel
Cc: WebApps WG
Subject: Fetch API
The plan is to implement and ship this fairly soon, so I figured I'd ask for
review now, while we're still drafting the text:
http://fetch.spec.whatwg.org/#fetch-api
In particular I'd like feedback on the design of Request and Response classes,
and the fetch() method.
--
http://annevankesteren.nl/
Re: Fetch API
On Thu, May 29, 2014 at 8:10 AM, Tobie Langel wrote:
> On Thu, May 29, 2014 at 4:58 PM, Marcos wrote:
>>
>>
>> > enum RequestMode { "same-origin", "tainted cross-origin", "CORS",
>> > "CORS-with-forced-preflight" };
>>
>> I think these are badly named (even though they use the names used in HTML
>> and Fetch). It's going to be annoying to type these out for developers.
>>
>> I would change them to:
>> enum RequestMode { "same-origin", "cors", "cors-tainted", "cors-preflight"
>> };
>
> I like those better.
>
> We want consistency with lowercasing or uppercasing cors/CORS in enums,
> though.
Yes. Lowercasing always, please.
~TJ
Re: Fetch API
On Thu, May 29, 2014 at 4:58 PM, Marcos wrote:
>
> > enum RequestMode { "same-origin", "tainted cross-origin", "CORS",
> "CORS-with-forced-preflight" };
>
> I think these are badly named (even though they use the names used in HTML
> and Fetch). It's going to be annoying to type these out for developers.
>
> I would change them to:
> enum RequestMode { "same-origin", "cors", "cors-tainted", "cors-preflight"
> };
>
I like those better.
We want consistency with lowercasing or uppercasing cors/CORS in enums,
though.
--tobie
Re: Fetch API
On May 29, 2014 at 9:02:35 AM, Anne van Kesteren (ann...@annevk.nl) wrote:
> The plan is to implement and ship this fairly soon, so I figured I'd
> ask for review now, while we're still drafting the text:
>
> http://fetch.spec.whatwg.org/#fetch-api
>
> In particular I'd like feedback on the design of Request and Response
> classes, and the fetch() method.
Having these interfaces exposed is going to be great!
Few small things that stood out for me...
> enum RequestMode { "same-origin", "tainted cross-origin", "CORS",
>"CORS-with-forced-preflight" };
I think these are badly named (even though they use the names used in HTML and
Fetch). It's going to be annoying to type these out for developers.
I would change them to:
enum RequestMode { "same-origin", "cors", "cors-tainted", "cors-preflight" };
And then map them to the appropriate concept in the specs.
> enum RequestOmitCredentialsMode { "always", "CORS", "never" };
The item "CORS" here is not self evident (unlike "always"/"never" modes). Can
you find a better word?
Re: Fetch API
http://fetch.spec.whatwg.org/#dom-request Add steps to set client and context? http://fetch.spec.whatwg.org/#cors-preflight-fetch-0 Add steps to set client and context? http://fetch.spec.whatwg.org/#concept-legacy-fetch http://fetch.spec.whatwg.org/#concept-legacy-potentially-cors-enabled-fetch Steps to set url, client and context are missing here too. But not worth updating this section anymore? Termination reason is not handled intentionally (only supposed to be used by XHR's functionalities and nothing would be introduced for Fetch API?)? The promise is rejected with a TypeError which seems inconsistent with XHR. Is this intentional?
