expo
expo copied to clipboard
DevTool network inspector can't resolve GZIP requests
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
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.
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.
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": {}
}
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
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
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?
I'm facing the same issue too
I have the same issue on Expo 50,
Accept-Encoding
is not defined but our endpoint returnsaccept-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
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 @mikmedina Unfortunately, the proposed solutions do not solve my problem (Expo SDK 49)
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 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]
I have the same issue on Expo 50,
Accept-Encoding
is not defined but our endpoint returnsaccept-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 defaultAccept-Encoding
of Android requests is gzip that's why the BE returns gzipContent-Type
Thanks, worked fine for fetchBaseQuery using RTK Query
Hi @Kudo,
Do you have any news about this issue ? It's still a thing using expo sdk@50
Regards