expo icon indicating copy to clipboard operation
expo copied to clipboard

DevTool network inspector can't resolve GZIP requests

Open LucasBourgeois opened this issue 1 year ago • 10 comments

Minimal reproducible example

https://github.com/LucasBourgeois/expo-gzip

Summary

In a newly created expo app :

To run the project : Clone or expo create an app.

  • npx create-expo-app expo-gzip
  • yarn install
  • yarn android

  • Open devtool
  • Look at network for the request
  • Response body and preview is broken.,

Request is a GZIP accepting content type. It's done in App.js file


Here the the problem:

Im requesting a server asking for a GZIP encoding type response. The server resolve the request successfully and give me a response in a GZIP encoded response.

Looking in the expo stock devtool debugger, in the network tab. Here the problems:

  • The request in always tagged as "Pending"
  • The request "Preview" tab is showing nothing.
  • The request "Response" tab is showing as below instead of a JSON.
�s�v���[t5��Ɏ$(����)�".@�A��חEu���fc��ܧ��`�)��~/e]�>$�ѝxh
7�P�%Lo�����5Q{뎝�BP�8���f��K%�7���x�6GJ��w<���1R��k�~(�jl�Ƞ��n��550z�3�g!LCa�5)��/�z���

For additionnal info: The response is successfull and request response is a valid JSON response. In Android Studio, app network inspector, the response is well decodded. In Ios, the chromium devtool is showing the response as a valid JSON and the issue is not occuring in IOS. If im asking for the server to give me a JSON response, everything is alright, but i really need to use GZIP.

Environment

expo-env-info 1.0.5 environment info: System: OS: macOS 13.2.1 Shell: 5.8.1 - /bin/zsh Binaries: Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node Yarn: 1.22.15 - /opt/homebrew/bin/yarn npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm Watchman: 2023.11.06.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: 1.11.3 - /usr/local/bin/pod SDKs: iOS SDK: Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1 IDEs: Android Studio: Giraffe 2022.3.1 Patch 1 Giraffe 2022.3.1 Patch 1 Xcode: 14.2/14C18 - /usr/bin/xcodebuild npmPackages: expo: ~49.0.15 => 49.0.18 react: 18.2.0 => 18.2.0 react-native: 0.72.6 => 0.72.6 Expo Workflow: managed

LucasBourgeois avatar Nov 13 '23 11:11 LucasBourgeois

Thank you for filing this issue! This comment acknowledges we believe this may be a bug and there’s enough information to investigate it. However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

expo-bot avatar Nov 14 '23 04:11 expo-bot

hi there! okhttp (the underlying network library of react-native android) supports transparent gzip. if you don't explicitly add the Accept-Encoding, it will gzip actually and network inspector would be correct.

i'm still accepting the issue given sometimes people would still like to have explicit Accept-Encoding. and will resolve the issue when i get a chance.

Kudo avatar Nov 14 '23 04:11 Kudo

Hello Nice to hear that.

To be more precise and give you all the tools : The explicit Accept-Encoding was for the exemple.

I can confirm you that the network inspector still have the problem described without defining an Accept-Encoding: gzip at all.

Here is the fetch httpOptions object that i normally use. No explicit Accept-Encoding: gzip is used but is still implicitly used by okHttp (see the screenshot) Im also using "PROPFIND" method http verb Even if im explicitly use Accept-Encoding: gzip, deflate, br the issue is still there.

{
    "method": "GET",
    "headers": {
        "accept-language": "en-GB",
        "authorization": /A BEARER TOKEN/
    },
    "cache": "no-store",
    "duplex": "half",
    "signal": {}
}

image


I can't screenshot you header through source inspector as the source inspector is giving every variables as undefined and breakings points not stopping at the right spot. :( But i thing it's an known issue also / not the subject here.

Regards

LucasBourgeois avatar Nov 14 '23 09:11 LucasBourgeois

I'm facing a similar issue. I'm using Axios and can only observe network responses in DevTools as gzip encoding, even though I'm dealing with application/JSON requests

mleister97 avatar Jan 08 '24 17:01 mleister97

I have the same issue on Expo 50, Accept-Encoding is not defined but our endpoint returns accept-encoding: gzip and is not decoded properly in the chrome devtools. Flipper's Network tab also seems to not be working when on Linux with Android Emulator... Might be related?

BrandonYuen avatar Jan 23 '24 15:01 BrandonYuen

I'm facing the same issue too

Code-Victor avatar Jan 28 '24 20:01 Code-Victor

I have the same issue on Expo 50, Accept-Encoding is not defined but our endpoint returns accept-encoding: gzip and is not decoded properly in the chrome devtools. Flipper's Network tab also seems to not be working when on Linux with Android Emulator... Might be related?

You can explicitly define headers.set('Accept-Encoding', '*') in your FE code. I noticed that the default Accept-Encoding of Android requests is gzip that's why the BE returns gzip Content-Type

mikmedina avatar Feb 04 '24 16:02 mikmedina

Thank you @mikmedina ! Adding Accept-Encoding: * temporarily solves the issue for Axios

if (process.env.NODE_ENV === "development") {
    axios.defaults.headers.common["Accept-Encoding"] = "*";
}

dr-zr avatar Feb 06 '24 10:02 dr-zr

@dr-zr @mikmedina Unfortunately, the proposed solutions do not solve my problem (Expo SDK 49)

image

const api = axios.create({
  baseURL: process.env.EXPO_PUBLIC_BACKEND_API_URI,
  headers: {
    Accept: 'application/json',
    'Content-Type': 'application/json',
    'Accept-Encoding': '*',
  },
  responseType: 'json',
  transitional: {
    clarifyTimeoutError: true,
  },
})

mleister97 avatar Feb 08 '24 15:02 mleister97

@mleister97 Unfortunately, I haven't tried this solution on v49. I've used Flipper to spoof network requests on v49. For now you can use it as a workaround until you upgrade to v50

This is how I've set it up. Can you try and see if this will work?

axios.defaults.headers.common = {
    Accept: "application/json",
    "Content-Type": "application/json",
    // other project specific headers 
};

if (process.env.NODE_ENV === "development") {
    axios.defaults.headers.common["Accept-Encoding"] = "*";
}

Axios version: [email protected]

dr-zr avatar Feb 09 '24 09:02 dr-zr

I have the same issue on Expo 50, Accept-Encoding is not defined but our endpoint returns accept-encoding: gzip and is not decoded properly in the chrome devtools. Flipper's Network tab also seems to not be working when on Linux with Android Emulator... Might be related?

You can explicitly define headers.set('Accept-Encoding', '*') in your FE code. I noticed that the default Accept-Encoding of Android requests is gzip that's why the BE returns gzip Content-Type

Thanks, worked fine for fetchBaseQuery using RTK Query

alexandrehaas avatar Mar 11 '24 16:03 alexandrehaas

Hi @Kudo,

Do you have any news about this issue ? It's still a thing using expo sdk@50

Regards

LucasBourgeois avatar Apr 23 '24 16:04 LucasBourgeois