Streamed events/flag updates don't work correctly when client device has an HTTP proxy enabled (mitmproxy)

[erawhctim]

Is this a support request?
No

Describe the bug
When mitmproxy is configured as the HTTP proxy for a host device, LD's Server-Sent Events don't work correctly. This doesn't seem to happen when proxying with other tools (e.g. Charles).

To reproduce

• Install mitmproxy
• Configure your host device's network to use mitmproxy as the HTTP proxy
• Use an app with LD enabled/configured/initialized
• Set up a flag listener via the SDK
• Update flag values in the LD web console
  • Those updates don't work and the listener isn't fired
• Disable the HTTP proxy; change the flag value in the web console
  • Now the listener fires and gets updates correctly.

I see something in the mitmproxy UI about a TLS handshake issue, but I don't have detailed info about what's going wrong.
I know this may not technically be a bug in LD, but I'd like to better understand how the SSE implementation works and help debug this issue with both you and the mitmproxy team (to try and diagnose where the issue lies).

Expected behavior
I expect the LD SDK to function the same way when proxying that it would without proxying

Logs
N/A; if there are specific logs I can do some digging to try and find something for you. Not sure where to look, exactly (I don't see anything in Logcat that seems related)

SDK version
v3.1.5

OS/platform
Android 10-12; multiple devices

Additional context
This isn't the most helpful report in terms of actionable info, apologies in advance... I'm happy to help dig in here further if I can figured out where to look.
I suspect this might be related to mitmproxy in isolation and not an issue with the SDK, but I don't know what I don't know and I'm mostly trying to get more context on SSE and TLS and how the SDK works in relation to both (and see if you all have any ideas on what is happening here, or where exactly I can dig deeper to investigate). If there is a "Discussions" area that is more appropriate to log this report, let me know and I can move it

We use mitmproxy pretty heavily on our team, and while moving to another proxying tool is an option, it's not an ideal one (so any help you can provide related to this would be greatly appreciated!)

[erawhctim]

Potentially related to #102 ? 🤷‍♂️

[cwaldren-ld]

Hi @erawhctim, thanks for the report.

As far as we can tell, mitmproxy doesn't support SSE. Other proxy software does (such as Proxyman and Fiddler).

Please see the linked issue for more context and a potential workaround.

[erawhctim]

Thank you for the link @cwaldren-ld! Extremely helpful context. I'll do some testing with Proxyman.

Do you think there's any value in trying to find a way to surface this information to LD users?
(either by detecting proxyman somehow, mentioning in the documentation, or something else entirely)

Curious to hear how you and the team approach these types of obscure integration issues, since this is technically outside of the boundaries of the LD SDK, but ultimately affects the SDKs behavior. We've run into this a few times with some of our testing and development teams and the outcome is mostly the same every time (people think the app is broken or that LD isn't working correctly); it's hard to know that the problem lies in the specific proxy tool.

[louis-launchdarkly]

Hello @erawhctim, sorry for the late reply and thank you for the comment, does Proxyman work for you?

While I can't quite say in particular for this case, in general, for the more obscure integration use cases, typically LaunchDarkly Support engineering is the group to help out here. It is hard to document all the edge cases and still keep the documentation easy to read, so instead, having a Support engineer actively work with the customer will resolve things faster.

[erawhctim]

Gotcha, that makes sense!

I never got around to testing Proxyman 😬 I'll give it a go and let you know