-
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
[bug/question]: Is multiplexing HTTP/1 and gRPC supported? #4095
Comments
i meet the same issue, have you have solved this issue? |
No. This is not supported by NGINX. You need to enable SSL. |
And it is even flaky if using TLS, see #4836 |
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug(?)
NGINX Ingress controller version: 0.22.0
Kubernetes version (use
kubectl version
): 1.12 (gke)Environment: GKE
What happened:
It appears that when running an upstream server with gRPC and HTTP/1 multiplexed on the same port Nginx ingress gRPC connection gets knocked down by drive-by HTTP/1 requests.
At first we were getting this error:
After I patched the nginx binary to ignore non-grpc keepalive connections - it still breaks further down:
4740180
is ascii-encodedHTT
so it appears it's getting stumbled on HTTP/1 reply when reading from upstream connection socket.What you expected to happen: Is having same ip:port upstream for both plain HTTP and gRPC supposed to work?
How to reproduce it (as minimally and precisely as possible):
Our generated config:
Our service definition:
Then we define two separate ingresses to match HTTP/1 and gRPC respectively and point them to the above service/port.
Is there a way to tell nginx to initiate new upstream connection instead of reusing existing socket that already exists from HTTP/1 one or there is something else I'm missing here?
The text was updated successfully, but these errors were encountered: