Summary:
Changelog: [Network] Non-binary request are not properly utf-8 decoded on both iOS and Android, both when gzipped and when not gzipped
This diff fixes a long standing / ping-pong issue regarding network decoding differences between
* iOS vs Android
* binary vs utf-8
* gzipped vs uncompressed
The changes aren't too big, but the underlying investigating is :)
The primary contribution to this diff is:
First, adding test cases for know problematic cases. This is done by grabbing the messages that are send from the flipper client to flipper using the flipper messages plugin. This is the base64 data that is stored in the `.txt` files. Beyond that, for all tests public endpoints are used, so that we can both get a hold of the raw original files, and how we expect them to be displayed in flipper.
For testing a simple RN app was build, with a button that fires a bunch requests. The first 3 are captured in unit tests, the last one is not idempotent, but a case reported in #1466, so just left it there as manual verification.
```
const fetchData = async () => {
await fetch(
'https://raw.githubusercontent.com/SangKa/MobX-Docs-CN/master/docs/donating.md',
{
headers: {
'Accept-Encoding': 'identity', // signals that we don't want gzip
},
},
);
await fetch('https://reactnative.dev/img/tiny_logo.png?x=' + Math.random());
await fetch(
'https://raw.githubusercontent.com/SangKa/MobX-Docs-CN/master/docs/donating.md',
);
await fetch(
'https://ex.ke.com/sdk/recommend/html/100001314?hdicCityId=110000¶mMap[source]=&id=100001314&mediumId=100000037&elementId=&resblockId=1111027381003&templateConfig=%5Bobject%20Object%5D&fbExpoId=346620976471638017&fbQueryId=&required400=true&unique=1111027381003&parentSceneId=',
);
};
```
The second contribution of this diff is that it doesn't use weird URLencoder hacks to convert base64 to utf8, but rather a proper library. The problem with our original solution, using `atob` is that it converts to ASCII, not to utf-8, which is the source of the original bugs. See for more background on this: https://www.npmjs.com/package/js-base64#decode-vs-atob-and-encode-vs-btoa-
Solves:
https://github.com/facebook/flipper/issues/1466https://github.com/facebook/flipper/pull/1541https://github.com/facebook/flipper/issues/1458
Supersedes D23837750
Future work: we don't inspect the `content-type=xxx;charset` header yet, which we should do for less common encodings, to make sure that they get displayed correctly as well
Future work: in feature like copy data and curl, we always call decode body, without check if we are actually dealing with non-binary data. Probably it is better to keep binary data in base64, rather than decoding it, as that will assume the data is an utf-8 string, which might fail.
An assumption in these changes is that binary data is never gzipped, which is generally correct; gzip is not applied by webserver to things like images, as it would increase, not decrease their size, and waste a lot of computation power.
Reviewed By: cekkaewnumchai
Differential Revision: D23403095
fbshipit-source-id: 5099cc4a7503f0f63bd10585dc6590ba893f3dde
Summary:
It's common for responses to be completely missing in the network inspector. This is because they are larger than can be serialized in one go on some devices, so we drop all messages larger than 1MB.
This changes the android client to send large responses in individually serialized batches. This way we avoid running out of memory and can still send arbitrarily large payloads.
Changelog: Android network inspector can now handle responses large than 1MB.
Reviewed By: passy
Differential Revision: D22999905
fbshipit-source-id: ff4eb8fa72a7e42ea90d12ffe0f20c6d1e58b7e5
