| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
`withCredentials` defaults to `false` on `XMLHttpRequest`, but the opposite was chosen in this library. This can cause difficult to understand failures depending on the CORS headers returned by the server (it's an issue when calling the GitHub v3 API for example). The alternative would be to default to `false` to stay consistent with `XMLHttpRequest`, but that is likely a breaking change for some downstream apps, and I am going to assume the current strategy was chosen for a reason.
The main issue preventing browserify usage was computed paths
in require statements: `require("./" + someVariable)`. Those have
all been eliminated.
This patch only adds browser support for `v3.0.0` (see the throwing
code in `/index.js` where it states exactly that to understand why).
Hint: it's related to computed paths again.
There were also a number of issues in `browserify-http`, and
`browserify-https` that I needed to code around to get things working:
- https://github.com/substack/https-browserify/pull/1
- browserify/http-browserify#90
- browserify/http-browserify#21
- browserify/http-browserify#10
|
Yeah, this was a surprise for me. It would be interesting if @substack could add to this PR to give the background for the withCredentials default. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
withCredentials defaults to false on XMLHttpRequest, but the opposite was chosen in this library. This can cause difficult to understand failures depending on the CORS headers returned by the server (it's an issue when calling the GitHub v3 API for example).
The alternative would be to default to false to stay consistent with XMLHttpRequest, but that is likely a breaking change for some downstream apps, and I am going to assume the current strategy was chosen for a reason.