aboutsummaryrefslogtreecommitdiff
path: root/node_modules/whatwg-fetch/README.md
diff options
context:
space:
mode:
authorFlorian Dold <florian.dold@gmail.com>2017-05-03 15:35:00 +0200
committerFlorian Dold <florian.dold@gmail.com>2017-05-03 15:35:00 +0200
commitde98e0b232509d5f40c135d540a70e415272ff85 (patch)
treea79222a5b58484ab3b80d18efcaaa7ccc4769b33 /node_modules/whatwg-fetch/README.md
parente0c9d480a73fa629c1e4a47d3e721f1d2d345406 (diff)
node_modules
Diffstat (limited to 'node_modules/whatwg-fetch/README.md')
-rw-r--r--node_modules/whatwg-fetch/README.md282
1 files changed, 282 insertions, 0 deletions
diff --git a/node_modules/whatwg-fetch/README.md b/node_modules/whatwg-fetch/README.md
new file mode 100644
index 000000000..328cb490e
--- /dev/null
+++ b/node_modules/whatwg-fetch/README.md
@@ -0,0 +1,282 @@
+# window.fetch polyfill
+
+The `fetch()` function is a Promise-based mechanism for programmatically making
+web requests in the browser. This project is a polyfill that implements a subset
+of the standard [Fetch specification][], enough to make `fetch` a viable
+replacement for most uses of XMLHttpRequest in traditional web applications.
+
+This project adheres to the [Open Code of Conduct][]. By participating, you are
+expected to uphold this code.
+
+## Table of Contents
+
+* [Read this first](#read-this-first)
+* [Installation](#installation)
+* [Usage](#usage)
+ * [HTML](#html)
+ * [JSON](#json)
+ * [Response metadata](#response-metadata)
+ * [Post form](#post-form)
+ * [Post JSON](#post-json)
+ * [File upload](#file-upload)
+ * [Caveats](#caveats)
+ * [Handling HTTP error statuses](#handling-http-error-statuses)
+ * [Sending cookies](#sending-cookies)
+ * [Receiving cookies](#receiving-cookies)
+ * [Obtaining the Response URL](#obtaining-the-response-url)
+* [Browser Support](#browser-support)
+
+## Read this first
+
+* If you believe you found a bug with how `fetch` behaves in Chrome or Firefox,
+ please **avoid opening an issue in this repository**. This project is a
+ _polyfill_, and since Chrome and Firefox both implement the `window.fetch`
+ function natively, no code from this project actually takes any effect in
+ these browsers. See [Browser support](#browser-support) for detailed
+ information.
+
+* If you have trouble **making a request to another domain** (a different
+ subdomain or port number also constitutes as another domain), please
+ familiarize yourself with all the intricacies and limitations of [CORS][]
+ requests. Because CORS requires participation of the server by implementing
+ specific HTTP response headers, it is often nontrivial to set up or debug.
+ CORS is exclusively handled by the browser's internal mechanisms which this
+ polyfill cannot influence.
+
+* If you have trouble **maintaining the user's session** or [CSRF][] protection
+ through `fetch` requests, please ensure that you've read and understood the
+ [Sending cookies](#sending-cookies) section.
+
+* If this polyfill **doesn't work under Node.js environments**, that is expected,
+ because this project is meant for web browsers only. You should ensure that your
+ application doesn't try to package and run this on the server.
+
+* If you have an idea for a new feature of `fetch`, please understand that we
+ are only ever going to add features and APIs that are a part of the
+ [Fetch specification][]. You should **submit your feature requests** to the
+ [repository of the specification](https://github.com/whatwg/fetch/issues)
+ itself, rather than this repository.
+
+## Installation
+
+* `npm install whatwg-fetch --save`; or
+
+* `bower install fetch`.
+
+You will also need a Promise polyfill for [older browsers](http://caniuse.com/#feat=promises).
+We recommend [taylorhakes/promise-polyfill](https://github.com/taylorhakes/promise-polyfill)
+for its small size and Promises/A+ compatibility.
+
+For use with webpack, add this package in the `entry` configuration option
+before your application entry point:
+
+```javascript
+entry: ['whatwg-fetch', ...]
+```
+
+For Babel and ES2015+, make sure to import the file:
+
+```javascript
+import 'whatwg-fetch'
+```
+
+## Usage
+
+For a more comprehensive API reference that this polyfill supports, refer to
+https://github.github.io/fetch/.
+
+### HTML
+
+```javascript
+fetch('/users.html')
+ .then(function(response) {
+ return response.text()
+ }).then(function(body) {
+ document.body.innerHTML = body
+ })
+```
+
+### JSON
+
+```javascript
+fetch('/users.json')
+ .then(function(response) {
+ return response.json()
+ }).then(function(json) {
+ console.log('parsed json', json)
+ }).catch(function(ex) {
+ console.log('parsing failed', ex)
+ })
+```
+
+### Response metadata
+
+```javascript
+fetch('/users.json').then(function(response) {
+ console.log(response.headers.get('Content-Type'))
+ console.log(response.headers.get('Date'))
+ console.log(response.status)
+ console.log(response.statusText)
+})
+```
+
+### Post form
+
+```javascript
+var form = document.querySelector('form')
+
+fetch('/users', {
+ method: 'POST',
+ body: new FormData(form)
+})
+```
+
+### Post JSON
+
+```javascript
+fetch('/users', {
+ method: 'POST',
+ headers: {
+ 'Content-Type': 'application/json'
+ },
+ body: JSON.stringify({
+ name: 'Hubot',
+ login: 'hubot',
+ })
+})
+```
+
+### File upload
+
+```javascript
+var input = document.querySelector('input[type="file"]')
+
+var data = new FormData()
+data.append('file', input.files[0])
+data.append('user', 'hubot')
+
+fetch('/avatars', {
+ method: 'POST',
+ body: data
+})
+```
+
+### Caveats
+
+The `fetch` specification differs from `jQuery.ajax()` in mainly two ways that
+bear keeping in mind:
+
+* The Promise returned from `fetch()` **won't reject on HTTP error status**
+ even if the response is an HTTP 404 or 500. Instead, it will resolve normally,
+ and it will only reject on network failure or if anything prevented the
+ request from completing.
+
+* By default, `fetch` **won't send or receive any cookies** from the server,
+ resulting in unauthenticated requests if the site relies on maintaining a user
+ session. See [Sending cookies](#sending-cookies) for how to opt into cookie
+ handling.
+
+#### Handling HTTP error statuses
+
+To have `fetch` Promise reject on HTTP error statuses, i.e. on any non-2xx
+status, define a custom response handler:
+
+```javascript
+function checkStatus(response) {
+ if (response.status >= 200 && response.status < 300) {
+ return response
+ } else {
+ var error = new Error(response.statusText)
+ error.response = response
+ throw error
+ }
+}
+
+function parseJSON(response) {
+ return response.json()
+}
+
+fetch('/users')
+ .then(checkStatus)
+ .then(parseJSON)
+ .then(function(data) {
+ console.log('request succeeded with JSON response', data)
+ }).catch(function(error) {
+ console.log('request failed', error)
+ })
+```
+
+#### Sending cookies
+
+To automatically send cookies for the current domain, the `credentials` option
+must be provided:
+
+```javascript
+fetch('/users', {
+ credentials: 'same-origin'
+})
+```
+
+The "same-origin" value makes `fetch` behave similarly to XMLHttpRequest with
+regards to cookies. Otherwise, cookies won't get sent, resulting in these
+requests not preserving the authentication session.
+
+For [CORS][] requests, use the "include" value to allow sending credentials to
+other domains:
+
+```javascript
+fetch('https://example.com:1234/users', {
+ credentials: 'include'
+})
+```
+
+#### Receiving cookies
+
+As with XMLHttpRequest, the `Set-Cookie` response header returned from the
+server is a [forbidden header name][] and therefore can't be programmatically
+read with `response.headers.get()`. Instead, it's the browser's responsibility
+to handle new cookies being set (if applicable to the current URL). Unless they
+are HTTP-only, new cookies will be available through `document.cookie`.
+
+Bear in mind that the default behavior of `fetch` is to ignore the `Set-Cookie`
+header completely. To opt into accepting cookies from the server, you must use
+the `credentials` option.
+
+#### Obtaining the Response URL
+
+Due to limitations of XMLHttpRequest, the `response.url` value might not be
+reliable after HTTP redirects on older browsers.
+
+The solution is to configure the server to set the response HTTP header
+`X-Request-URL` to the current URL after any redirect that might have happened.
+It should be safe to set it unconditionally.
+
+``` ruby
+# Ruby on Rails controller example
+response.headers['X-Request-URL'] = request.url
+```
+
+This server workaround is necessary if you need reliable `response.url` in
+Firefox < 32, Chrome < 37, Safari, or IE.
+
+## Browser Support
+
+- Chrome
+- Firefox
+- Safari 6.1+
+- Internet Explorer 10+
+
+Note: modern browsers such as Chrome, Firefox, and Microsoft Edge contain native
+implementations of `window.fetch`, therefore the code from this polyfill doesn't
+have any effect on those browsers. If you believe you've encountered an error
+with how `window.fetch` is implemented in any of these browsers, you should file
+an issue with that browser vendor instead of this project.
+
+
+ [fetch specification]: https://fetch.spec.whatwg.org
+ [open code of conduct]: http://todogroup.org/opencodeofconduct/#fetch/opensource@github.com
+ [cors]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
+ "Cross-origin resource sharing"
+ [csrf]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
+ "Cross-site request forgery"
+ [forbidden header name]: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name