New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable follow redirect #137

Closed
vslinko opened this Issue May 5, 2015 · 9 comments

Comments

Projects
None yet
7 participants
@vslinko
Copy link

vslinko commented May 5, 2015

Quote from standard:

A request has an associated redirect mode, which is one of "follow", "error", and "manual". Unless stated otherwise, it is "follow".

A request has an associated redirect count. Unless stated otherwise, it is zero.
@josh

This comment has been minimized.

Copy link
Member

josh commented May 5, 2015

I don't think this is going to be possible to polyfill on top of XHR.

@domenic

This comment has been minimized.

Copy link

domenic commented May 5, 2015

I don't think this is exposed in the API anyway. Those sentences have no bearing on window.fetch.

@saschanaz

This comment has been minimized.

Copy link

saschanaz commented Dec 30, 2015

@dgraham Hi, can you reopen this issue?

https://www.chromestatus.com/features/4614142321229824

https://fetch.spec.whatwg.org/#requestredirect

JS use:

fetch(new Request(url, {redirect: 'manual'}))
@dgraham

This comment has been minimized.

Copy link
Member

dgraham commented Dec 31, 2015

This is a nice addition to the Fetch API, but we won't be able to polyfill it with XMLHttpRequest. The browser navigates all redirects before returning a result, so there is no opportunity to interrupt the redirect flow.

If the response has an HTTP status code of 301, 302, 303, 307, or 308…Set the request URL to the URL conveyed by the Location header…transparently follow the redirect…

XMLHttpRequest specification

@saschanaz

This comment has been minimized.

Copy link

saschanaz commented Jan 1, 2016

That's right but I think we can at least mimic redirect: error using responseURL attribute, (unfortunately) after redirection.

@mislav

This comment has been minimized.

Copy link
Member

mislav commented Jan 2, 2016

@saschanaz We could make a clumsy support for redirect: error, but that would only provide a partial and imperfect support for the redirect setting. I'd rather that we don't support this at all in the polyfill.

@saschanaz

This comment has been minimized.

Copy link

saschanaz commented Jan 3, 2016

@mislav That's reasonable, thanks :)

@axelson

This comment has been minimized.

Copy link
Contributor

axelson commented Feb 25, 2016

Is this difference from the standard documented anywhere?

@mislav

This comment has been minimized.

Copy link
Member

mislav commented Feb 26, 2016

@axelson I don't think so. You're welcome to add it to our documentation in the "gh-pages" branch seen here when published.

xg-wang added a commit to xg-wang/pretender that referenced this issue May 23, 2018

fetch support
tl;dr
- This commit add support for fetch.
- pretender swap native fetch related API if exists
- pretender.shutdown() restore native fetch related API
- doesn't work with AbortController

Pretender has been working well with xhr, but doesn't handle fetch.
It's been 2 years since @rwjblue first open the
[issue](pretenderjs#60) for fetch
support. So people don't need to do extra work to polyfill for testing.

Include a fetch ponyfill and swap the native fetch during pretender
creation, then restore them when `shutdown`. Since fetch polyfill uses
xhr behind the scene, pretender will "just work".

Per Yetch homepage, the supplement set of yetch impl and spec include:
- Inability to [set the redirect mode](github/fetch#137)
- Inability to [change the cache directive](github/fetch#438 (comment))
- Inability to [disable same-origin cookies](github/fetch#56 (comment))

- `xhr.abort()` first set state to done, finally response to a [network error](https://xhr.spec.whatwg.org/#the-abort()-method);
- [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will reject promise with a new "AbortError" DOMException.

For `fake_xml_http_request` impl, the request is resolved once its state is changed to `DONE` so the `reject` is not cathed.

So the senario happens in pretender is:
1. state chagne to `DONE`, trigger resolve request
2. abort, trigger reject
3. xhr.onerror, trigger reject

The first resolve wins, error thus not rejected but an empty request is resolved.

Though polyfilled by xhr, fetch returns a Promise and is asynchronous by
nature.

xg-wang added a commit to xg-wang/pretender that referenced this issue May 23, 2018

fetch support
tl;dr
- This commit add support for fetch.
- pretender swap native fetch related API if exists
- pretender.shutdown() restore native fetch related API
- doesn't work with AbortController

Motivation
------
Pretender has been working well with xhr, but doesn't handle fetch.
It's been 2 years since @rwjblue first open the
[issue](pretenderjs#60) for fetch
support. So people don't need to do extra work to polyfill for testing.

Changes
------
Include a fetch ponyfill and swap the native fetch during pretender
creation, then restore them when `shutdown`. Since fetch polyfill uses
xhr behind the scene, pretender should "just work".

Caveats
------
1. The supplement set of yetch impl and spec includes (not complete):
- Inability to [set the redirect mode](github/fetch#137)
- Inability to [change the cache directive](github/fetch#438 (comment))
- Inability to [disable same-origin cookies](github/fetch#56 (comment))

2. Abort
- `xhr.abort()` first set state to done, finally response to a [network error](https://xhr.spec.whatwg.org/#the-abort()-method);
- [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will reject promise with a new "AbortError" DOMException.

As implemented in `fake_xml_http_request`, the request is resolved once its
state is changed to `DONE`.
So the senario happens in pretender is:
  1). state chagne to `DONE`, trigger resolve request
  2). abort, trigger reject
  3). xhr.onerror, trigger reject
The first resolve wins, error thus not rejected but an empty request is resolved.

3. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by
nature.

xg-wang added a commit to xg-wang/pretender that referenced this issue May 23, 2018

fetch support
tl;dr
- This commit adds support for fetch.
- pretender swap native fetch related API if exists
- pretender.shutdown() restore native fetch related API
- doesn't work with AbortController

Motivation
------
Pretender has been working well with xhr, but doesn't handle fetch.
It's been 2 years since @rwjblue first open the
[issue](pretenderjs#60) for fetch
support. So people don't need to do extra work to polyfill for testing.

Changes
------
Include a fetch ponyfill and swap the native fetch during pretender
creation, then restore them when `shutdown`. Since fetch polyfill uses
xhr behind the scene, pretender should "just work".

Caveats
------
1. The supplement set of yetch impl and spec includes (not complete):
- Inability to [set the redirect mode](github/fetch#137)
- Inability to [change the cache directive](github/fetch#438 (comment))
- Inability to [disable same-origin cookies](github/fetch#56 (comment))

2. Abort
- `xhr.abort()` first set state to done, finally response to a
[network error](https://xhr.spec.whatwg.org/#the-abort()-method);
- [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will
reject promise with a new "AbortError" DOMException.

As implemented in `fake_xml_http_request`, the request is resolved once its
state is changed to `DONE`.
So the senario happens in pretender is:
  1). state changes to `DONE`, trigger resolve request
  2). abort, trigger reject
  3). xhr.onerror, trigger reject
The first resolve wins, error thus not rejected but an empty request is resolved.

3. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by
nature.

xg-wang added a commit to xg-wang/pretender that referenced this issue May 23, 2018

fetch support
tl;dr
- This commit adds support for fetch, fix pretenderjs#60.
- pretender swap native fetch related API if exists
- pretender.shutdown() restore native fetch related API
- doesn't work with AbortController

Changes
------
Include a fetch ponyfill and swap the native fetch during pretender
creation, then restore them when `shutdown`. Since fetch polyfill uses
xhr behind the scene, pretender should "just work".

Caveats
------
1. The supplement set of yetch impl and spec includes (not complete):
- Inability to [set the redirect mode](github/fetch#137)
- Inability to [change the cache directive](github/fetch#438 (comment))
- Inability to [disable same-origin cookies](github/fetch#56 (comment))

2. Abort
- `xhr.abort()` first set state to done, finally response to a
[network error](https://xhr.spec.whatwg.org/#the-abort()-method);
- [fetch](https://dom.spec.whatwg.org/#aborting-ongoing-activities) will
reject promise with a new "AbortError" DOMException.

As implemented in `fake_xml_http_request`, the request is resolved once its
state is changed to `DONE`.
So the scenario happens in pretender is:
  1). state changes to `DONE`, trigger resolve request
  2). abort, trigger reject
  3). xhr.onerror, trigger reject
The first resolve wins, error thus not rejected but an empty request is resolved.

3. Though polyfilled by xhr, fetch returns a Promise and is asynchronous by
nature.

@xg-wang xg-wang referenced this issue May 23, 2018

Merged

fetch support #230

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment