react-native: `Fetch` no longer returns all rows of the same-name response headers after RN Upgrade
- I have reviewed the documentation
- I have searched existing issues
- I am using the latest React Native version
Fetch
is no longer returning all rows of the same-name response headers! This only just happened after recent upgrade.
Environment
Environment: OS: Windows 10 Node: 9.2.0 Yarn: 1.3.2 npm: 5.8.0 Watchman: Not Found Xcode: N/A Android Studio: Version 3.0.0.0 AI-171.4443003
Packages: (wanted => installed) react: 16.3.1 => 16.3.1 react-native: ^0.55.3 => 0.55.3
Steps to Reproduce
Server returns the following response
return response()->json(['msg'=>'1'], 200)
->withHeaders(['Content-Type'=>'application/json', 't1'=>[1, 2]]);
** react native code **
let response = await fetch('http://im-sick-and-tired-of-hunting-react-native-bugs',
{
credentials: 'include',
method: 'GET',
cache: 'no-cache',
mode: 'cors',
headers: {'Cache-Control': 'no-cache', 'Accept':'*/*', 'Content-Type':'application/json'},
});
console.log(response.headers.get('t1'));
Expected Behavior
The test hdr (t1) must have both values but only the 2nd one is received. See the response from postman
Actual Behavior
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 12
- Comments: 21 (1 by maintainers)
I am having this issue on
v.0.57
.I found a workaround for this issue, but I’m not sure of any additional implications of it. Inspired by comments on a
ReadableNativeArray
issue, if you add the following lines toMainApplication.java
, the duplicate headers are properly parsed:I created a repo to reproduce the issue using 0.55.4: https://github.com/patricksmith/rn-headers. You can see the workaround in this commit: https://github.com/patricksmith/rn-headers/commit/e666aa814bf36616d73e015bef75654fc315ec10. I can’t find any documentation on what
setUseNativeAccessor
is doing, so it may have additional unintended repercussions.Our app was also affected by this when trying to update to 0.55.4. It breaks use case of reading cookies from responses as there’s often more than one
set-cookie
headers in one response.I’ve also just ran into this problem. It seems to be an issue with the
WritableMap
that collects the response headers in thetranslateHeaders()
method incom.facebook.react.modules.network.NetworkingModule
. The code checks to see if the key exists in the map, but for some reason it returns false. Debugging the code, it callshasKey()
onReadableNativeMap
. This drops down to the local map sincemUseNativeAccessor
is false, and the local map is empty.Facing the same issue, spent the morning trying to debug why on iOS we had 3 cookies and on Android only 1 cookie and the problem happens when there are more headers with the same name, on Android it takes only the last one ignoring the others.
An easy way to reproduce, using an express server
Then on the app
On Android you get
mattia2=world; Path=/
On iOS you getmattia1=hello; Path=/, mattia2=world; Path=/
Only if you control the server the workaround is to not send 2 headers of the same type
In this case with cookies you have to manually set the header with
We were affected by this issue after upgrading our Android app from RN 0.53.3 to RN 0.54.4, and I see that it’s still an issue in RN 0.55.4. We’re using an API that returns multiple
Link
headers and we’re now only receiving one of those headers in our app.Same issue affect our app when moving from RN 0.52 The server we are connecting to returns Basic & Digest authentication headers but in the Android app we only get the Basic authentication header returned. The same servers work OK on iOS
I’m seeing the same thing happening since upgrading from RN 0.52 to 0.54.
Headers being returned by some servers we use have the same fields spread across multiple lines. Since 0.54 it is not possible to talk to these devices any more using RN on Android! RN on iOS is fine.
This is still an issue on RN
v0.57.0-rc.3
Also have same issue after upgrading RN version 0.53 to 0.55. fetch() is not returning body returned by the server. When I downgraded to RN version 0.53, it works well. Please give the solution.