Question about the setup about grpc-web-cloud-run-issue

[merlinnot]

Hi! In this reproduction we were using a gRPC back end and an Envoy proxy deployed as two separate Cloud Run services. This setup works thanks to a host rewrite in the proxy (host is changed from the proxy URL to the back end URL).

[wlhee]

Yeah. I understand how the two Cloud Run services are chained together.

My question is more about in the actual production setup, is the envoy proxy deployed as a separate service that dispatches to different backend services, or it's deployed as a side car runs along side with the gRPC service?

It sounds like to me the envoy is a separate service?

[merlinnot]

Yes, Envoy is a separate service. We did consider running them inside of the same container (as Cloud Run doesn't support sidecars per se), but there are a lot of things that need to be taken care of for such a setup to actually work and we use Envoy solely for gRPC-web transcoding - in reality a large portion of the traffic (from clients that support gRPC natively) would travel through a proxy unnecessarily.

[wlhee]

Gotcha. I will try something to see if we can workaround the content-length: 0 issue for empty response.

[wlhee]

I updated the envoy.yaml to remove the content-length header. It looks like once the C-L is removed, the js client starts working as expected. See the example PR: c734a5e

[wlhee]

Also filed an issue to grpc-web: grpc/grpc-web#1101

[merlinnot]

Thanks! Do you think we should open an issue against Envoy as well?

[wlhee]

I am not very sure if this is a really bug in envoy, because a regular gRPC client works with C-L: 0 in the resposne.

[merlinnot]

I see. I don't have access to an internal issue mentioned here: grpc/grpc-web#1101 (comment). I'll follow that issue for now. Again, many thanks for looking into this.

[wlhee]

No problem!

The internal issue is the same one your team filed.