Firestore blocked by corporate proxy

[Ben Delsol]

Hi,

This is related to getting the error:

@firebase/firestore: Firestore (5.0.4): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds.
This typically indicates that your device does not have a healthy Internet connection at the moment. The client will operate in offline mode until it is able to successfully connect to the backend.

I wanted to let Google Cloud Firestore know that in my case we had to bypass SSL protocol detection for firestore.googleapis.com in order to allow our corporate Bluecoat proxy to let Firestore XHRs through.

I don't know if this is because of the way Firestore sends its XHRs or what. I'm not an expert in this department at all. But I wanted to post about so others could find this solution and Firestore devs could look into it.

May not be specific to Bluecoat proxy. From online searches seems other proxy's may block Firestore as well.

[Kato Richardson]

Hi Ben,

I think the primary issue here is that the SDKs aren't using XHR in the default ; they're communicating via Web Sockets (see XHR vs WebSockets and proxies).

For what it's worth, it looks like there was an experiment to try working around similar issues and a plan to integrate it into the official SDKs at some point. 

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/06e4ddf8-8a2d-4388-b0ca-88d93310c4cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Michael Lehenbauer]

Hey just want to chime in here and clarify that actually Firestore doesn't use WebSockets at all (Realtime Database does).  Firestore always uses XHRs, but by default the backend will keep the XHR response open for up to ~1min so that it can continue to stream messages down as necessary.  We've noticed this causes occasional problems with misbehaving proxies that try to buffer the entire response rather than proxying the bytes as they arrive.  This causes large latency and timeouts.  The workaround Kato mentioned (https://github.com/firebase/firebase-js-sdk/issues/1190#issuecomment-456886973) should help if that is indeed the case.

Thanks for the heads-up about Bluecoat proxy.  Any chance you'd be interested in starting a support request with them to see if they could improve their proxy behavior on their end?  Feel free to loop me in and I can try to provide any necessary technical details.

Thanks,

Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEaPr1Kv8n2Mmoa5tBEDVmcQYK2vvy37_FgseXnODW6AXw%40mail.gmail.com.