Commit Graph

4 Commits

Author SHA1 Message Date
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