Summary:
Brotli response decoding was introduced via https://github.com/facebook/flipper/pull/4288, and released in 0.177.0. We noticed from that release that many of our iOS response bodies were not being rendered. It simply showed `(empty)` in the `Response Body` section.
As noted in the gzip decoder ([here](2a52656d0b/desktop/plugins/public/network/utils.tsx (L117-L119))) within Flipper, iOS already provides an inflated `data` value, so it doesn't need inflating again.
This PR adds a best-effort guess to detect when the same problem arises in the Brotli decoder.
I'm definitely not a Brotli expert, but according to [this SO post](https://stackoverflow.com/questions/39008957/is-there-a-way-to-check-if-a-buffer-is-in-brotli-compressed-format), there's no sure-fire way to detect Brotli data, and some blobs of random data will still present as Brotli. We may still occasionally see false positives that continue to show `(empty)`, however in my testing, all of our server responses have rendered JSON responses perfectly.
The library used for decoding doesn't throw an error on failure with any responses we've seen, it just simply returns a 0-length buffer. So the naïve approach taken in this PR simply looks for a 0-length output buffer on a non-zero-length input buffer, and concludes "probably not Brotli, shrug emoji".
## Changelog
Ignore Brotli decode result on 0-length return value
Pull Request resolved: https://github.com/facebook/flipper/pull/4632
Test Plan:
We can use Facebook's servers to test this. Fire up a RN app, and add the following somewhere you can run it:
```typescript
fetch('https://graph.facebook.com/facebook/picture?redirect=false', {
headers: {
'accept-encoding': 'br',
},
})
```
Before this patch, we can see that `Response Body` is `(empty)` in Flipper:
<img width="1211" alt="Screenshot 2023-03-30 at 1 26 48 am" src="https://user-images.githubusercontent.com/33126/228690254-988b5a01-5d7b-4ab3-b6dc-49f3b0607d10.png">
But after this patch, we can see some valid JSON in the `Response Body`:
<img width="1213" alt="Screenshot 2023-03-30 at 1 26 07 am" src="https://user-images.githubusercontent.com/33126/228690351-9611759a-5b7d-4ccb-9170-22b950c8afbe.png">
Most importantly, both responses have `Content-Encoding: br` headers.
Reviewed By: passy
Differential Revision: D46219337
Pulled By: mweststrate
fbshipit-source-id: 2ae775d381fa325c6d9e543bdbc617d1fd986671
Summary: Buffer is not available in the browser
Reviewed By: lblasa
Differential Revision: D44416645
fbshipit-source-id: 9cca069b8b0111f96bb47628e5f2196a22c9812d
Summary:
Using this network tab explorer at a company that works in graphql is very difficult because everything comes from the same HTTP route. I've added support for an optional (not visible by default) "GraphQL operation name" field for people who want to use that.
## Changelog
Adds a new optional column in the desktop network plugin called "GraphQL operation name" which will display the operation name if its available.
Pull Request resolved: https://github.com/facebook/flipper/pull/4625
Test Plan:
I didn't see much in the way of component testing for this behaviour. Looking for some guidance here. I'm happy to add some if we think that makes sense
https://user-images.githubusercontent.com/17029928/227016610-b6da1ff3-4a7e-45c6-88da-ceaa6fad53ad.mp4
Reviewed By: ivanmisuno
Differential Revision: D44331605
Pulled By: aigoncharov
fbshipit-source-id: fe7a7812541c235871ae8a71e5461ea2adbd2560
Summary:
Flipper network plugin does not show request payload size at all, only the response.
I was trying to use flipper to check the compression ratio and overall analytics log size, but wasn't able to it, so fixed the network plugin
Reviewed By: lblasa
Differential Revision: D34062808
fbshipit-source-id: f4d4395eece9d41380b8ac6f834a014315c5db66
Summary:
Changelog: [Network] The network plugin will now detect utf-8 strings if no content header is present
Fixes https://github.com/facebook/flipper/issues/2406
Reviewed By: nikoant
Differential Revision: D29388968
fbshipit-source-id: 7017828a5f3f28dcf220eeda1d30888f1fc5f07a
Summary:
Network requests and responses using JSON API content type of pattern `application/vnd.api+json` (see https://jsonapi.org/#mime-types) are currently treated as binary data. They should be treated as textual content.
## Changelog
Add regular expression to detect JSON content types.
Pull Request resolved: https://github.com/facebook/flipper/pull/2337
Test Plan: Using an API that return `Content-Type` of pattern `application/vnd.api+json`, verify that the response data in sidebar appears as text rather than `(binary data)`.
Reviewed By: passy
Differential Revision: D28513547
Pulled By: mweststrate
fbshipit-source-id: 3335b7eeb63c2429c2245113c8c83bd7e08a9420
Summary:
Network requests that return a "Content-Type" of 'application/xhtml+xml' are currently being treated as binary data when they should be treated as text.
## Changelog
Network Plugin - treat "Content-Type" of 'application/xhtml+xml' as text
Pull Request resolved: https://github.com/facebook/flipper/pull/2336
Test Plan: Using an API that return "Content-Type" of 'application/xhtml+xml' , verified that the response data in sidebar appears as text rather than '(binary data)'
Reviewed By: nikoant
Differential Revision: D28478695
Pulled By: mweststrate
fbshipit-source-id: ed60c8301dbd0cf65924a80d9e6a5800a59c6bb8
Summary:
Currently the network plugin was always storing the transfer format of our request/ response bodies: a base64 string. However, those are not searchable, and every formatter (and multiple can be invoked in a single view) was responsible for its own decompressing.
This diff changes parsing requests / responses into an accurate format: a decompressed, de-base64-ed utf8 string, or a Uint8array for binary data.
We will use this in the next diffs to do some more efficient searching
Reviewed By: passy
Differential Revision: D28200190
fbshipit-source-id: 33a71aeb7b340b58305e97fff4fa5ce472169b25
Summary:
Changelog: Updated Network plugin to Sandy UI, including several UI improvements
Converted UI to Sandy, and some minor code cleanups
Moved all mock related logic to its own dir
Fixes https://github.com/facebook/flipper/issues/2267
Reviewed By: passy
Differential Revision: D27966606
fbshipit-source-id: a64e20276d7f0966ce7a95b22557762a32c184cd
Summary:
converted the network plugin to use DataSource / DataTable. Restructured the storage to contain a single flat normalised object that will be much more efficient for rendering / filtering (as columns currently don't support nested keys yet, and lazy columns are a lot less flexible)
lint errors and further `flipper` package usages will be cleaned up in the next diff to make sure this diff doesn't become too large.
The rest of the plugin is converted in the next diff
Reviewed By: nikoant
Differential Revision: D27938581
fbshipit-source-id: 2e0e2ba75ef13d88304c6566d4519b121daa215b
Summary:
Here I'm changing plugin repository structure to allow re-using of shared packages between both public and fb-internal plugins, and to ensure that public plugins has their own yarn.lock as this will be required to implement reproducible jobs checking plugin compatibility with released flipper versions.
Please note that there are a lot of moved files in this diff, make sure to click "Expand all" to see all that actually changed (there are not much of them actually).
New proposed structure for plugin packages:
```
- root
- node_modules - modules included into Flipper: flipper, flipper-plugin, react, antd, emotion
-- plugins
--- node_modules - modules used by both public and fb-internal plugins (shared libs will be linked here, see D27034936)
--- public
---- node_modules - modules used by public plugins
---- pluginA
----- node_modules - modules used by plugin A exclusively
---- pluginB
----- node_modules - modules used by plugin B exclusively
--- fb
---- node_modules - modules used by fb-internal plugins
---- pluginC
----- node_modules - modules used by plugin C exclusively
---- pluginD
----- node_modules - modules used by plugin D exclusively
```
I've moved all public plugins under dir "plugins/public" and excluded them from root yarn workspaces. Instead, they will have their own yarn workspaces config and yarn.lock and they will use flipper modules as peer dependencies.
Reviewed By: mweststrate
Differential Revision: D27034108
fbshipit-source-id: c2310e3c5bfe7526033f51b46c0ae40199fd7586
