Skip to content
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

About cache option #438

Closed
poppinlp opened this issue Nov 17, 2016 · 4 comments
Closed

About cache option #438

poppinlp opened this issue Nov 17, 2016 · 4 comments

Comments

@poppinlp
Copy link

Seems cache option not work in this polyfill.
It's hard to do polyfill for some cache mode such as force-cache. But we could support behavior similar to no-store by query string at least.
So do you think it is necessary to do this?
I think it will be convenient if this option is available, although I could assemble the URL outside.

@mislav
Copy link
Contributor

mislav commented Nov 17, 2016

There are some things we are not able to polyfill due to limitations with XMLHttpRequest. This is one of them. Sure, we could maybe support no-store by appending a cache-busting parameter to the URL, but I'd rather not tamper with URLs. Also, it doesn't make sense to implement just one of the possible cache options while not supporting the others.

@dgraham dgraham closed this as completed Nov 17, 2016
@poppinlp
Copy link
Author

OK got it. THX

@serbanghita
Copy link

@mislav this is really an issue on IE11, would you be interested in review-ing a PR for this?

xg-wang pushed a commit to xg-wang/pretender that referenced this issue May 23, 2018
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](JakeChampion/fetch#137)
- Inability to [change the cache directive](JakeChampion/fetch#438 (comment))
- Inability to [disable same-origin cookies](JakeChampion/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 pushed a commit to xg-wang/pretender that referenced this issue May 23, 2018
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](JakeChampion/fetch#137)
- Inability to [change the cache directive](JakeChampion/fetch#438 (comment))
- Inability to [disable same-origin cookies](JakeChampion/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 pushed a commit to xg-wang/pretender that referenced this issue May 23, 2018
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](JakeChampion/fetch#137)
- Inability to [change the cache directive](JakeChampion/fetch#438 (comment))
- Inability to [disable same-origin cookies](JakeChampion/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 pushed a commit to xg-wang/pretender that referenced this issue May 23, 2018
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](JakeChampion/fetch#137)
- Inability to [change the cache directive](JakeChampion/fetch#438 (comment))
- Inability to [disable same-origin cookies](JakeChampion/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.
@jslegers
Copy link

jslegers commented May 30, 2018

There are some things we are not able to polyfill due to limitations with XMLHttpRequest. This is one of them.

I understand that you may not be able to polyfill all behavior of IE, but I would expect that IE11's caching behavior is the same as that of other browsers when no cache settings are provided.

IMO, default behavior should be the same in polyfilled and non-polyfilled browsers.

Also, it doesn't make sense to implement just one of the possible cache options while not supporting the others.

It makes even less sense to have different default behavior in a polyfilled browser than in the other browsers. This kind of defeats the purpose of using a polyfill.

See #629.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants
@mislav @dgraham @jslegers @serbanghita @poppinlp and others