Commit Graph

16 Commits

Author SHA1 Message Date
Steven Cable b21d4914de Check return code from malloc (#20173)
Summary:
Calls abort() in cases where malloc returns NULL.

Checking the return value from malloc is good practice and is
required to pass a [Veracode security scan](https://www.veracode.com/). This will let
developers who are required to submit their software to Veracode
use React Native.
Pull Request resolved: https://github.com/facebook/react-native/pull/20173

Differential Revision: D9235096

Pulled By: hramos

fbshipit-source-id: 9fdc97f9e84f8d4d91ae59242093907f7a81d286
2018-08-08 18:32:19 -07:00
Jose Pereira b805172034 Clear _handlers on RCTNetworking invalidation
Summary:
This PR fixes a bug where in `RCTNetworking` not all tasks/handlers were not being cleared when invalidating the class.

I came across this issue when writing some unit tests for my native plugins, sometimes a test would finish running (and the bridge invalidated), and only afterwards a callback from RCTNetworking would come, resulting in this exception:

```
2018-05-07 15:23:34.264494-0700 Guardian[73794:10710945] *** Assertion failure in -[RCTEventEmitter sendEventWithName:body:](), /Users/.../app/node_modules/react-native/React/Modules/RCTEventEmitter.m:41
2018-05-07 15:23:34.276505-0700 Guardian[73794:10710945] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error when sending event: didCompleteNetworkResponse with body: (
    2,
    cancelled,
    0
). Bridge is not set. This is probably because you've explicitly synthesized the bridge in RCTNetworking, even though it's inherited from RCTEventEmitter.'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000010d5b21e6 __exceptionPreprocess + 294
	1   libobjc.A.dylib                     0x000000010be6f031 objc_exception_throw + 48
	2   CoreFoundation                      0x000000010d5b7472 +[NSException raise:format:arguments:] + 98
	3   Foundation                          0x000000010b94864f -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 165
	4   Guardian                            0x0000000106ff5227 -[RCTEventEmitter sendEventWithName:body:] + 567
	5   Guardian                            0x0000000106e9ebab __76-[RCTNetworking sendRequest:responseType:incrementalUpdates:responseSender:]_block_invoke.423 + 1115
	6   Guardian                            0x0000000106e8f48c __50-[RCTNetworkTask URLRequest:didCompleteWithError:]_block_invoke + 92
	7   Guardian                            0x0000000106e8ded1 -[RCTNetworkTask dispatchCallback:] + 113
	8   Guardian                            0x0000000106e8f37a -[RCTNetworkTask URLRequest:didCompleteWithError:] + 410
	9   Guardian                            0x0000000106ea1aa3 -[RCTHTTPRequestHandler URLSession:task:didCompleteWithError:] + 403
	10  CFNetwork                           0x000000010cf3a437 __51-[NSURLSession delegate_task:didCompleteWithError:]_block_invoke.207 + 80
	11  Foundation                          0x000000010b885363 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 7
	12  Foundation                          0x000000010b8851ca -[NSBlockOperation main] + 68
	13  Foundation                          0x000000010b8836b2 -[__NSOperationInternal _start:] + 766
	14  libdispatch.dylib                   0x0000000112457779 _dispatch_client_callout + 8
	15  libdispatch.dylib                   0x000000011245c931 _dispatch_block_invoke_direct + 317
	16  libdispatch.dylib                   0x0000000112457779 _dispatch_client_callout + 8
	17  libdispatch.dylib                   0x000000011245c931 _dispatch_block_invoke_direct + 317
	18  libdispatch.dylib                   0x000000011245c7d4 dispatch_block_perform + 109
	19  Foundation                          0x000000010b87f75b __NSOQSchedule_f + 337
	20  libdispatch.dylib                   0x0000000112457779 _dispatch_client_callout + 8
	21  libdispatch.dylib                   0x000000011245f1b2 _dispatch_queue_serial_drain + 735
	22  libdispatch.dylib                   0x000000011245f9af _dispatch_queue_invoke + 321
	23  libdispatch.dylib                   0x0000000112461cf8 _dispatch_root_queue_drain + 473
	24  libdispatch.dylib                   0x0000000112461ac1 _dispatch_worker_thread3 + 119
	25  libsystem_pthread.dylib             0x000000011297a169 _pthread_wqthread + 1387
	26  libsystem_pthread.dylib             0x0000000112979be9 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
```

Bug can be reproduced by making a `XMLHttpRequest` (uses `RCTNetworking` internally) that takes a couple seconds to perform, and issuing a RCTBridge reload command in the meantime.

You can add the following code to the react-native template project,

```
  componentDidMount() {
    var oReq = new XMLHttpRequest();
    oReq.addEventListener("load", () => console.log('Finished'));
    oReq.open("GET", "https://www.dropbox.com/s/o01hz0chqvjafhv/file.bin?dl=1");
    oReq.send();
    console.log('Request is being performed...')
  }
```
In my case I download a 1MB file.
Run the project and reload the a couple times. Bug is triggered.

 [INTERNAL] [BUGFIX] [RCTNetworking] - Clear handlers and tasks on RCTNetworking invalidation
Closes https://github.com/facebook/react-native/pull/19169

Differential Revision: D8053070

Pulled By: hramos

fbshipit-source-id: d8af54fecd99173905363f962ffc638ef8b85082
2018-05-17 19:10:48 -07:00
Janic Duplessis f5207ba9c7 Fix blob response parsing for empty body on iOS
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
2018-03-27 11:13:34 -07:00
Sophie Alpert 1490ab12ef Update license headers for MIT license
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
2018-02-16 18:31:53 -08:00
Satyajit Sahoo be56a3efee Implement Blob support for XMLHttpRequest
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:

![screen shot 2017-06-08 at 7 53 08 pm](https://user-images.githubusercontent.com/1174278/26936407-435bbce2-4c8c-11e7-9ae3-eb104e46961e.png)!

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
2018-01-26 09:17:11 -08:00
Chris Lewis 1c04ceeb4b Check against integer overflow in RCTNetworking decodeTextData
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
2017-11-07 08:08:41 -08:00
Seraj Ahmad 047961fbf7 Added Cookie Header to XML and Websocket request
Summary:
Continuation of Pull Request #7167

https://github.com/facebook/react-native/pull/7167

Needed to clean my repository. So created this Pull Request
Closes https://github.com/facebook/react-native/pull/10575

Differential Revision: D4955291

Pulled By: shergin

fbshipit-source-id: 94b9a086b7cf70ee6cc152d0b1a36c260140450e
2017-05-24 09:47:37 -07:00
Adam Comella 454ab8fc23 BREAKING: iOS: Support withCredentials flag in XHRs
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
2017-03-08 06:15:15 -08:00
Pieter De Baets 7d51580479 Use weakSelf in RCTNetworking callbacks
Reviewed By: shergin

Differential Revision: D4551000

fbshipit-source-id: fcfce41adb8fd76343b973339ffe1cac0bf8a756
2017-02-13 12:29:58 -08:00
Philipp von Weitershausen 16bb6e87ba XHR: support typed arrays for request payloads
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
2017-01-20 18:43:27 -08:00
unordered 8ec774396c fix ios formdata boundary include slash
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
2016-12-14 08:28:42 -08:00
Pieter De Baets e1577df1fd Move all header imports to "<React/..>"
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
2016-11-23 07:58:39 -08:00
Saleeh 27ae04cabd Fixed #7564
Summary:
Fix for some firewall with ModSecurity
 rules for MULTIPART_STRICT_ERROR, namely MULTIPART_BOUNDARY_QUOTED.
Closes https://github.com/facebook/react-native/pull/10876

Reviewed By: javache

Differential Revision: D4176229

Pulled By: ericvicenti

fbshipit-source-id: 8db819bd3e9b23fa3c1802c48091bb4c44358381
2016-11-15 08:44:30 -08:00
Leo Natan 3ac3749ac3 Fix for Unicode decoding issue when using incremental networking.
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:

![example1](https://cloud.githubusercontent.com/assets/2270433/18829964/5a54ff30-83e7-11e6-9806-97857dce0430.png)

![example2](https://cloud.githubusercontent.com/assets/2270433/18829966/5bf40a66-83e7-11e6-84e6-9e4d76ba4f8b.png)

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
2016-10-31 13:13:38 -07:00
Adam Comella 9304df3e3d For file uploads, don't stomp on developer's Content-Type header
Summary:
Currently when doing a file upload, the Content-Type header gets set to whatever MIME type iOS computed for the file. The Content-Type header the developer provided never takes precedence.

For example, when uploading an image, iOS might determine that the MIME type is "image/jpeg" and so this would be the Content-Type of the HTTP request. But the developer might need the Content-Type to be "application/octet-stream". With this change, if the developer provides a Content-Type header, it will not be overriden.

There is only one exception to this rule which is for "multipart" requests. In this case, the developer's Content-Type header is always ignored. This is because the Content-Type header needs to contain the boundary string and that information is not available to the developer in JavaScript.

This change makes iOS's behavior more consistent with Android's.

**Test plan (required)**

In a small test app, verified that the developer's Content-Type header takes precedence when it's provided. Verif
Closes https://github.com/facebook/react-native/pull/9651

Differential Revision: D3820001

Pulled By: mkonicek

fbshipit-source-id: fdb8871f88a0d0db1ae59f75bb62b896fe69542d
2016-09-05 14:58:40 -07:00
Marc Horowitz a8cf12a932 Fix some unsafe thread behavior
Reviewed By: javache

Differential Revision: D3789293

fbshipit-source-id: 80118c7f8faf487fe35d4d83a91f023219f6bf80
2016-09-01 19:58:58 -07:00