Incorrect Request implementation

[cesarandreu]

Operating system: OS X Yosemite Version 10.10.4
Browser: Safari Version 8.0.7 (10600.7.12)

I've been developing with the following browsers:

• Firefox Developer Edition 41.0a2 (2015-07-14)
• Google Chrome Canary Version 46.0.2456.0 canary (64-bit)

Both Firefox and Chrome implement the expected behavior.

Code sample:

var request = new Request('/foo')
console.log(request.url)
// Chrome: "https://babeljs.io/foo"
// Safari: "/foo"

var request2 = new Request(request)
console.log(request2.url)
// Chrome: "https://babeljs.io/foo"
// Safari: {"url":"/foo","credentials":"omit","headers":{"map":{}},"method":"GET","mode":null,"referrer":null,"_bodyText":""}

The implementation in this repository is always taking the first parameter and setting it as the URL, but this is inconsistent with the standard, which allows you to pass a Request instance as the first parameter.

In the short-term, please consider adding a note to the README to inform users of this inconsistency. Tracking down this issue in Safari proved to be quite tricky for my project.

[mislav]

Are you using fetch v0.8 or greater? ab1ac93

[cesarandreu]

Yeah, I'm on v0.9.

The problem is caused because when you create a new Request from an existing request, it's always setting the first param as the url. The spec for the Request class' first param is RequestInfo, and the typedef says it can be a USVString or a Request.

var r = new Request('/foo')
console.log(r.url)

var f = new Request(r)
console.log(f.url)

fetch(f)

If you try out the code above, in Safari it'll fetch /[object%20Object] instead of /foo.

[mislav]

Ah, I see now. You're passing a Request to a Request constructor. I don't think we support that case yet. Thanks for reporting.

[cesarandreu]

@mislav could we get a new release of whatwg-fetch :D?