Gah, PhantomJS doesn't implement 308.

is Response.prototype.url supposed to be the redirected location?

Section 4.2 steps 4.4 and 4.10 say yes.

@josh XMLHttpRequest has responseURL these days. (And yes, it is the URL of the of the actual response.)

XMLHttpRequest has responseURL these days.

Nice! but looks like Safari still doesn't. I doubt IE does either. I wonder what we should set response.url to in the case that responseURL is undefined.

In a pre-responseURL world, github.com sends back a X-Request-URL header on every XHR. Then we can getResponseHeader that value. wdyt about this polyfill suggesting a similar fallback?

1. Try responseURL
2. Try getResponseHeader('X-Request-URL')
3. Fallback to the originally requested url. Will be wrong if a redirect happened, but mostly right otherwise.

All tests pass on Chrome Canary (native fetch), Chrome and Firefox. Currently failing on Safari and IE because of missing responseURL.

I'm hesitant to move some of our github.com header logic into the polyfill. The native fetch implementations won't have that header, so polyfill users could become dependent on non-standard behavior that disappears when browsers enable window.fetch natively.

The native fetch implementations won't have that header

Native implementations already do the right thing. The header does nothing in that case.