Summary:
We currently handle empty body poorly in the iOS blob implementation, this happens because of an early return that cause the blob response to not be processed by the blob module, resulting in an empty string as the body instead of a blob object. We also need to make sure to create an empty blob object when data is nil (empty body) as per the XMLHttpRequest spec. The Android implementation was already handling this properly.
Fixes#18223
Send a HEAD request
```js
fetch('https://apipre.monkimun.com/whoami', {
body: null,
method: 'HEAD',
headers: {
Accept: 'application/json',
'Content-Type': 'application/json',
},
})
```
[IOS][BUGFIX][Blob] - Fix blob response parsing for empty body
Closes https://github.com/facebook/react-native/pull/18547
Differential Revision: D7415950
Pulled By: hramos
fbshipit-source-id: 56860532c6171255869f02a0960f55d155184a46
Summary: The pull request that added this (#17397) simply forgot to remove the callback, which would cause crashes if the RCTNetInfo module was ever deallocated. While that usually doesn't happen in apps, it can if the user logs out and you need to wipe all the RCT modules (to remove user data, for instance).
Reviewed By: PeteTheHeat
Differential Revision: D7322999
fbshipit-source-id: e49ec7311b39920f7b7743a5854c0dda1dbccc73
Summary:
This is fixing #8615. The problem was that, on initialization, the `_connectionType` variable was still set to its default value of `RCTConnectionTypeUnknown`. The exposed API method did nothing to determine this unless a subscription had be established and then the method would simply return the last reported value. Instead, the exposed oneshot API call now actually checks the connection status through the same methods as the subscription and updates RCTNetInfo’s values before returning.
In order to avoid reporting events without a subscription, a flag is set and unset on calls to start/stopObserving.
- start app
- observe the (in)correct reporting of the manual status
- change network status to offline
- press refresh
- observe the manual fetch
- start subscription
- change network status to online
- press refresh to show that the manual refresh works (only now working for current RN version)
- change network status to offline
- stop subscription
- change network status to online
- press refresh to show manual refresh does(n't) work without subscription
- start subscription to show it updates to current
Current Behavior: https://drive.google.com/file/d/1Ods6HORgp_vfm1mQVjGwhtH1D7issxjo/view?usp=sharing
Fixed Behavior: https://drive.google.com/file/d/11H1UOF33LeMGvXEOoapU62ARDSb7qoYv/view?usp=sharing
[IOS] [BUGFIX] [Libraries\Network\RCTNetInfo.m] - Fixed#8615, `iOS: NetInfo.isConnected returns always false`, by decoupling the fetch from the status of the subscription.
Closes https://github.com/facebook/react-native/pull/17397
Differential Revision: D7102771
Pulled By: hramos
fbshipit-source-id: ea11eb0b1a7ca641fc43da2fe172cf7b2597de4a
Summary:
Hi! I would like to contribute to React Native, and I am just starting out. I forked the repo and found that it has quite a lot of ESLint warnings – many of which were automatically fixable. This PR is simply the result of running `yarn lint --fix` from the root folder.
Most changes are removing trailing spaces from comments.
Haven't really done any manual testing, since I haven't done any code changes manually. `yarn test` runs fine, `yarn flow` runs fine, `yarn prettier` is satisfied.
N/A
[INTERNAL][MINOR][] - Fix ESLint warnings
Closes https://github.com/facebook/react-native/pull/18047
Differential Revision: D7054948
Pulled By: hramos
fbshipit-source-id: d53e692698d1687de5821c3fb5cdb76a5e03b71e
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
This PR is a followup to https://github.com/facebook/react-native/pull/11417 and should be merged after that one is merged.
1. Add support for creating blobs from strings, not just other blobs
1. Add the `File` constructor which is a superset of `Blob`
1. Add the `FileReader` API which can be used to read blobs as strings or data url (base64)
1. Add support for uploading and downloading blobs via `XMLHttpRequest` and `fetch`
1. Add ability to download local files on Android so you can do `fetch(uri).then(res => res.blob())` to get a blob for a local file (iOS already supported this)
1. Clone the repo https://github.com/expo/react-native-blob-test
1. Change the `package.json` and update `react-native` dependency to point to this branch, then run `npm install`
1. Run the `server.js` file with `node server.js`
1. Open the `index.common.js` file and replace `localhost` with your computer's IP address
1. Start the packager with `yarn start` and run the app on your device
If everything went well, all tests should pass, and you should see a screen like this:
!
Pull to rerun all tests or tap on specific test to re-run it
[GENERAL] [FEATURE] [Blob] - Implement blob support for XMLHttpRequest
Closes https://github.com/facebook/react-native/pull/11573
Reviewed By: shergin
Differential Revision: D6082054
Pulled By: hramos
fbshipit-source-id: cc9c174fdefdfaf6e5d9fd7b300120a01a50e8c1
Summary:
It's currently possible to crash React Native on iOS when using XMLHTTPRequest with onreadystatechange by having the server send a bunch of bad unicode (we found the problem when a bad deploy caused this to happen).
This is due to an integer overflow when handling carryover data in decodeTextData.
Create Express server with mock endpoint:
```js
var express = require('express');
var app = express();
app.get('/', function(req, res) {
res.writeHead(200, {'content-type': 'text/plain; charset=utf-8'});
res.flushHeaders();
res.write(new Buffer(Array(4097).join(0x48).concat(0xC2)));
res.write(new Buffer([0xA9]));
res.end();
});
app.listen(3000);
```
Create React Native application which tries to hit the endpoint:
```js
export default class App extends Component<{}> {
componentDidMount() {
const xhr = new XMLHttpRequest()
xhr.open('get', 'http://localhost:3000', true);
xhr.onreadystatechange = function () {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.warn(xhr.responseText);
}
};
xhr.send();
}
render() {
return null;
}
}
```
Observe that the application crashes when running master and doesn't when including the changes from this pull request.
[IOS] [BUGFIX] [RCTNetworking] - |Check against integer overflow when parsing response|
Closes https://github.com/facebook/react-native/pull/16286
Differential Revision: D6060975
Pulled By: hramos
fbshipit-source-id: 650e401a3bc033725078ea064f8fbca5441f9db5
Summary:
The first code block already uses the new `connectionChange` event instead of
the deprecated `change` event, so change this example code block as well to use
the new event.
I came across this while upgrading my RN version. In the debug-console I saw a deprecation warning, despite I was using the example-code. Looking at the source, I saw the example code block still used the deprecated event, so update it to use the new one.
Closes https://github.com/facebook/react-native/pull/16357
Differential Revision: D6054428
Pulled By: hramos
fbshipit-source-id: 72ef1a79ece7494cda3773461a740dbbdf383e7e
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary:
This change intends to fix 2 issues with the NetInfo API:
- The NetInfo API is currently platform-specific. It returns completely different values on iOS and Android.
- The NetInfo API currently doesn't expose a way to determine whether the connection is 2g, 3g, or 4g.
The NetInfo API currently just exposes a string-based enum representing the connectivity type. The string values are different between iOS and Andorid. Because of this design, it's not obvious how to achieve the goals of this change without making a breaking change. Consequently, this change deprecates the old NetInfo APIs and introduces new ones. Specifically, these are the API changes:
- The `fetch` method is deprecated in favor of `getConnection`
- The `change` event is deprecated in favor of the `connectionchange` event.
- `getConnection`/`connectionchange` use a new set of enum values compared to `fetch`/`change`. See the documentation for the new values.
- On iOS, `cell` is now known as `cellular`. It's worth pointing out this one in particular because the old and new names are so similar. The rest of the iOS values have remained the same.
- Some of the Android enum values have been removed without a replacement (e.g. `DUMMY`, `MOBILE_DUN`, `MOBILE_HIPRI`, `MOBILE_MMS`, `MOBILE_SUPL`, `VPN`). If desirable, we could find a way to expose these in the new API. For example, we could have a `platformValue` key that exposes the platform's enum values directly (like the old `fetch` API did).
`getConnection` and `connectionchange` each expose an object which has 2 keys conveying a `ConnectionType` (e.g. wifi, cellular) and an `EffectiveConnectionType` (e.g. 2g, 3g). These enums and their values are taken directly from the W3C's Network Information API spec (https://wicg.github.io/netinfo/). Copying the W3C's API will make it easy to expose a `navigation.connection` polyfill, if we want, in the future. Additionally, because the new APIs expose an object instead of a string, it's easier to extend the APIs in the future by adding keys to the object without causing a breaking change.
Note that the W3C's spec doesn't have an "unknown" value for `EffectiveConnectionType`. I chose to introduce this non-standard value because it's possible for the current implementation to not have an `effectiveConnectionType` and I figured it was worth representing this possibility explicitly with "unknown" instead of implicitly with `null`.
**Test Plan (required)**
Verified that the methods (`fetch` and `getConnection`) and the events (`change` and `connectionchange`) return the correct data on iOS and Android when connected to a wifi network and a 4G cellular network. Verified that switching networks causes the event to fire with the correct information. Verified that the old APIs (`fetch' and 'change') emit a deprecation warning when used. My team is using a similar patch in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14618
Differential Revision: D5459593
Pulled By: shergin
fbshipit-source-id: f1e6c5d572bb3e2669fbd4ba7d0fbb106525280e
Summary:
- [X] Explain the **motivation** for making this change.
- [X] Provide a **test plan** demonstrating that the code is solid.
- [X] Match the **code formatting** of the rest of the codebase.
- [X] Target the `master` branch, NOT a "stable" branch.
`Promise.done` is non-standard, `Promise.then` is preferred as a standardized method. On Android, polyfill filling in `Promise.done` has been most probably taken out in newer versions of `react-native` and app crashes when it tries to query network state through `NetInfo`.
No tests are required for this change.
Closes https://github.com/facebook/react-native/pull/13489
Differential Revision: D4897566
Pulled By: mkonicek
fbshipit-source-id: 140720d7367cd1d9bf8924ec8a118c1bff4e461d
Summary:
Corresponding iOS PR: #12275
Respect the withCredentials XMLHttpRequest flag for sending cookies with requests. This can reduce payload sizes where large cookies are set for domains.
This should fix#5347.
This is a breaking change because it alters the default behavior of XHR. Prior to this change, XHR would send cookies by default. After this change, by default, XHR does not send cookies which is consistent with the default behavior of XHR on web for cross-site requests. Developers can restore the previous behavior by passing `true` for XHR's `withCredentials` argument.
**Test plan (required)**
Verified in a test app that XHR works properly when specifying `withCredentials` as `true`, `false`, and `undefined`. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12276
Differential Revision: D4673646
Pulled By: ericvicenti
fbshipit-source-id: 924c230c9df72071b3cf9151c3ac201905ac28a5
Summary:
This is enforced for all of our internal iOS code and a common cause of import failures.
cc janicduplessis
Closes https://github.com/facebook/react-native/pull/13124
Differential Revision: D4765016
fbshipit-source-id: 7c8248c98bca0fa6bad24d5a52b666243375e0db
Summary:
Corresponding Android PR: #12276
Respect the withCredentials XMLHttpRequest flag for sending cookies with requests. This can reduce payload sizes where large cookies are set for domains.
This should fix#5347.
This is a breaking change because it alters the default behavior of XHR. Prior to this change, XHR would send cookies by default. After this change, by default, XHR does not send cookies which is consistent with the default behavior of XHR on web for cross-site requests. Developers can restore the previous behavior by passing `true` for XHR's `withCredentials` argument.
**Test plan (required)**
Verified in a test app that XHR works properly when specifying `withCredentials` as `true`, `false`, and `undefined`. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12275
Differential Revision: D4673644
Pulled By: mkonicek
fbshipit-source-id: 2fd8f536d02fb39d872eb849584c5c4f7e7698c5
Summary:
04d870b added support for onabort in XHRs. The other on* events are declared on XMLHttpRequest and XMLHttpRequestEventTarget. This adds onabort there as well.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12277
Differential Revision: D4673648
Pulled By: mkonicek
fbshipit-source-id: 0c5255da77537103c5ad91d9b2826d064140708d
Summary:
Largely typing fixes to deal with the glut of new `FlowFixMe` suppressions introduced with flow 0.38 in a4bfac907e
Tested with flow itself. CC gabelevi
Closes https://github.com/facebook/react-native/pull/11985
Differential Revision: D4452045
Pulled By: ericvicenti
fbshipit-source-id: acc46c4c406ae706a679e396be1d40ae2f4ce5a1
Summary:
Support `xhr.send(data)` for typed arrays.
**Test plan:** run UIExplorer example on iOS and Android.
Closes https://github.com/facebook/react-native/pull/11904
Differential Revision: D4425551
fbshipit-source-id: 065ab5873407a406ca4a831068ab138606c3361b
Summary:
some server not work when upload a file with FromData in ios.
the reason is that there is a slash in boundary, like:
```
multipart/form-data; boundary=b/QeEbFgqK9PCZo4T/eXv7f.T74SHd5MxCZ846AsTz-yNV0xrRR_Zks4fkNMCzJck9ZE8o
// koa request.js (line 548)
is(types) {
if (!types) return typeis(this.req);
if (!Array.isArray(types)) types = [].slice.call(arguments);
return typeis(this.req, types);
}
// type-is index.js (line 237)
function normalizeType (value) {
// parse the type
var type = typer.parse(value)
// remove the parameters
type.parameters = undefined
// reformat it
return typer.format(type)
}
// media-typer
var paramRegExp = /; *([!#$%&'\*\+\-\.0-9A-Z\^_`a-z\|~]+) *= *("(?:[ !\u0023-\u005b\u005d-\u007e\u0080-\u00ff]|\\[\u0020-\u007e])*"|[!#$%&'\*\+\-\.0-9A-Z\^_`a-z\|~]+) */g;
```
thanks for dougwilson 's [answer](https://github.com/jshttp/media-typer/issues/5).
> The / is an illegal character for Content-Type, which is what this module parses
Closes https://github.com/facebook/react-native/pull/11342
Differential Revision: D4326750
Pulled By: javache
fbshipit-source-id: b1c78a335c95a5c223537545d87beaffe15d673d
Summary:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary: Adds methods in XMLHttpRequest so that the agent can hook the events needed for the implementation, these are only enabled if the agent is enabled (which means that the inspector is connected), it is also stripped out in non-dev currently.
Reviewed By: davidaurelio
Differential Revision: D4021516
fbshipit-source-id: c0c00d588404012d20b744de74e5ecbe5c002a53
Summary:
This is **a critical issue**.
The issue arises when incremental networking is enabled from JS by setting `onprogress` or `onload` on an `XMLHttpRequest` object.
The results:
Unicode characters get corrupted seemingly in random. The issue is from the way Unicode character parsing is handled in `RCTNetworking.mm`. When incremental networking is enabled, each chunk of data is decoded and passed to JS:
```objective-c
incrementalDataBlock = ^(NSData *data, int64_t progress, int64_t total) {
NSString *responseString = [RCTNetworking decodeTextData:data fromResponse:task.response];
if (!responseString) {
RCTLogWarn(@"Received data was not a string, or was not a recognised encoding.");
return;
}
NSArray<id> *responseJSON = @[task.requestID, responseString, @(prog
Closes https://github.com/facebook/react-native/pull/10110
Reviewed By: yungsters
Differential Revision: D4101533
Pulled By: fkgozali
fbshipit-source-id: 2674eaf0dd4568889070c6cde5cdf12edc5be521
Summary:
In the `NetworkingModule.java`, `header.getString(1)` was
called, so the value must be String type.
FIX#10198
Closes https://github.com/facebook/react-native/pull/10222
Differential Revision: D4080319
Pulled By: lacker
fbshipit-source-id: 85234a2bbf90e5b9e0e65ceadbfabb330b2d1322
Janic Duplessis
Mehdi Mulani
Adam Burdette
Mats Byrkeland
Sophie Alpert
Héctor Ramos
Satyajit Sahoo
Eli White
Yujie Liu
Chris Lewis
Miguel Jimenez Esun
Willem Fibbe
Marshall Roch
Adlai Holler
Jiajie Zhu
Adam Comella
Kathy Gray
James Burnett
Alex Dvornikov
Daniel Zlotin
Seraj Ahmad
Jakub Šimo
Pieter De Baets
Pieter De Baets
Matthew Oaxaca
rh389
Philipp von Weitershausen
Gabe Levi
unordered
Saleeh
Jeff Morrison
Alexander Blom
Leo Natan
leeight
Cristian Carlesso
