Clarify whether fetch method and Request accept URL instances

[mislav]

In fetch(url) and new Request(url) invocations, can url be an instance of URL? The spec is not clear.

This example shows that fetch() should likely accept URL:

var url = new URL("https://geo.example.org/api"),
    params = {lat:35.696233, long:139.570431}
Object.keys(params).forEach(key => url.searchParams.append(key, params[key]))
fetch(url).then(/* … */)

However, when I look at the spec itself, the first argument for Request constructor is defined as "RequestInfo", and later on it states:

5. If input is a string, then run these substeps: …
6. Otherwise (input is a Request object), run these substeps: …

This suggests that the argument may only be "USVString" or Request, and that behavior concerning other types is undefined, or—as I interpret it—that any non-string type will be treated as Request and that an exception will be thrown if the type doesn't look like a Request.

The spec also suggests that the behavior of the fetch() method is identical to new Request() because the arguments to fetch() are forwarded to Request constructor. It follows that fetch() too only accepts string or Request as argument.

Google Chrome's implementation, however, seems to treat any non-Request argument as a url by converting it to a string. Example:

new Request({ toString: () => "foo" }).url
// => "https://github.com/whatwg/fetch/issues/foo"

[annevk]

Welkom!

Part of the behavior of the API is defined through IDL. So https://fetch.spec.whatwg.org/#requestinfo is indeed either a Request or a string. However, what that means is that the binding layer (the bit IDL defines) will first check if the passed argument is a Request object and otherwise invoke ToString() on it (plus a couple of other things). And URL objects in turn, have a toString() defined (basically returning the value that the href getter returns). Combined, that gives the behavior you are observing.

Going to tentatively close this, but I'll happily respond to any further queries.

[mislav]

Thanks for explaining! I guess we will have to tweak our polyfill to match this behavior. I wasn't aware that this conversion happens at the binding layer (I have little familiarity with IDL). But, the end behavior makes sense to me.

[annevk]

See https://heycam.github.io/webidl/#es-USVString and how https://heycam.github.io/webidl/#dfn-overload-resolution-algorithm handles strings near the end for the full details, but beware, it's rather involved.