-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gRPC servers cannot use dynamic HPACK #2405
Comments
@stevewolter thank you for the report |
Closing. Please check response in nginx ticket |
@stevewolter @aledbf Hi. You concluded this to be a bug in nginx. JFYI but it seems like one in grpc-go.
We already have an issue in grpc/grpc-go#1928, and the PR is in-p at grpc/grpc-go#2045 That being said, using a grpc-go built from the PR head would solve this issue. Anyway, this is a bug outside of ingress-nginx. I just wanted to leave a note 😉 |
Thanks for the pointers, much appreciated. |
There is a workaround that fixes this issues https://trac.nginx.org/nginx/ticket/1397#comment:13 |
Any updates on this? I am trying to use ArgoCD behind some ingress rules and this is preventing me from using the ArgoCD CLI which depends on GRPC. |
@keatz55 please use 0.19.0. That version already uses NGINX 1.15.3 |
@aledbf I see that the change made it into the 1.15.3 release and I am using 0.19.0, however, I am still getting the following error while trying to use GRPC:
|
/reopen |
@zengyuxing007: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
NGINX Ingress controller version: 0.13.0
Kubernetes version (use
kubectl version
): v1.8.8-gke.0Environment: GKE
What happened:
I ran a golang gRPC server behind an nginx ingress. Many (but not all) RPCs fail with 502. nginx logs show "upstream sent invalid http2 table index: 64 while reading response header from upstream".
What you expected to happen:
No error.
How to reproduce it (as minimally and precisely as possible):
(since this is an upstream bug, I'm not including full repro)
Anything else we need to know:
This is a bug in nginx (https://trac.nginx.org/nginx/ticket/1538#ticket), I'm posting a bug here for reference.
The text was updated successfully, but these errors were encountered: