Cannot read Set-Cookie response header when network inspect enabled

[rsouthgate]

Unsure if this is fixable here or a limitation of the underlying lib - electron?

Basically I need to read the Set-Cookie response headers in a fetch request. When the network inspect is disabled this is fine, but when enabled these headers are getting removed somewhere upstream.

React Native Debugger app version: 0.9.7 React Native version: 0.58.6 Platform: iOS Is real device of platform: Yes Operating System: macOS

[ichiyouji]

@rsouthgate this also happens to me, I'm on RN version 59.9, and RN debugger version 0.9.10

[rsouthgate]

@ichiyouji Yep, it's a limitation of the way network inspect extends the xmlhttprequest object - I guess originally coming from the browser world where that header is an instruction to the browser and isn't for the client app that would normally be running within the browser.

It's not specifically listed in these limitations: https://github.com/jhen0409/react-native-debugger/blob/master/docs/network-inspect-of-chrome-devtools.md#limitations but it's related to them.

When I last thought about it I came to the conclusion that this could be solved by using the RN fetch/xmlhttprequest interface across the RN bridge which would have the side effect of running the same code with debugging on and off... but that's a big ask.

At least when not inspecting network traffic but debugging everything else it is accessible so I could live with it.

[ichiyouji]

@rsouthgate I see, thanks for the insight

[MusicalEcho]

@ichiyouji Yep, it's a limitation of the way network inspect extends the xmlhttprequest object - I guess originally coming from the browser world where that header is an instruction to the browser and isn't for the client app that would normally be running within the browser.

It's not specifically listed in these limitations: https://github.com/jhen0409/react-native-debugger/blob/master/docs/network-inspect-of-chrome-devtools.md#limitations but it's related to them.

When I last thought about it I came to the conclusion that this could be solved by using the RN fetch/xmlhttprequest interface across the RN bridge which would have the side effect of running the same code with debugging on and off... but that's a big ask.

At least when not inspecting network traffic but debugging everything else it is accessible so I could live with it.

Does that mean, that we cannot use cookie? Because after debugging a little I saw that there isnt anySet-cookie` header with network enabled

[ichiyouji]

@MusicalEcho the app I'm currently working on use cookie stored in async storage for authorization because it's using an API designed for the pre-existing web app.

Try turning off the network inspect and log the response.header on the console. If everything is correct, the Set-Cookie header should be present.

The downside is that when I'm debugging, I have to turn off network inspect when the app is invoking a request that returns a Set-Cookie header. If the network inspect is on, the Set-Cookie header will be missing as you described.

[LoverFancy]

Is there any plan to support can set cookies when open the network inspect feature when useing RND? @rsouthgate

[philipjames44]

Following

[TacticCoder]

A little bit information on this problem, in fact, its not a browser limitation. When we use the Network Inspect option all of the requests made by the Mobile app is proxied by localhost server build with webpack-dev-server, since that server is a localhost http server that try to reach a remotes services that fails on the security level so the Set-Cookie never been set correctly. That what i found.

[evangrim]

This needs to be explicitly mentioned in the docs; I suggest an item on the troubleshooting page, AND a mention in readme.md because for those of us it affects, it's important to be aware of.

I'm grateful to have this tool available, but not only is this a nuisance in using RND, it cost me fully two days in the middle of a large, time-sensitive app update. (Since I had changed so much code, it took me a long time to discover RND was the cause!)

BTW I'm on MacOS 11.6, RN 68.5, RND 0.13.