-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Fix http2 authority header in multiple endpoints scenario and bump up grpc from v1.51.0
to v1.52.0
#16324
Conversation
Signed-off-by: Chao Chen <[email protected]>
e2e test TestAuthority also needs update since it verifies the authority header value only matches the first endpoint. I need to replace etcdctl with etcd client or somehow send at least 3 requests to round-robin it. TIL: run
|
|
Ping @ahrtr @serathius @jmhbnz @fuweid Please review commit by commit. First one is just updating gRPC version. Second one is updating |
We either:
Both solutions seem work, and I do not see it will break anything with either solution. But based on @dfawley's comment in grpc/grpc-go#5748 (comment), it seems that he likes option 2 above (setting |
Also I suggest to bump gRPC to a more latest version, e.g. 1.56.2 or 1.57.0. |
No, authority header value should contains port. It is based on RFC. https://www.rfc-editor.org/rfc/rfc3986#section-3.2.3 |
port is optional.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me.
Maybe we can consider changing the title with Fix http2 authority header in multiple endpoints scenario
I vote for this. If the endpoint is just ip:port, and according to RFC, it's valid to have port here. It doesn't look correct if we just have IP here. |
I'm not sure about the details in the test you're referring to, but by default, gRPC will use the full "endpoint" portion of the dial target as the authority (ref). It's very common to dial
This is important. If you're using experimental APIs and your users upgrade to the latest version (or if one of their dependencies does), then you will break them if you are not keeping up with recent and upcoming changes, e.g. grpc/grpc-go#6363, grpc/grpc-go#6451, and the changes announced here grpc/grpc-go#6472. (I.e. #15145) |
thx @dfawley for the feedback. Then let's upgrade to 1.52 for now, and will take a closer look at the links you mentioned later. |
Thanks for calling it out. It's indeed a risk. ref. https://go.dev/ref/mod#minimal-version-selection |
v1.51.0
to v1.52.0
v1.51.0
to v1.52.0
Signed-off-by: Chao Chen <[email protected]>
Just as the original 3.5.0 issue #13192 stated, the use case is putting etcd server behinds proxy. With that in mind, etcd client (based on gRPC client support on proxy) first needs to establish connection with the proxy with CONNECT method. https://www.rfc-editor.org/rfc/rfc7540#section-8.3 The proxy server needs to know which etcd server it should connect to from the authority header. So that's why port should be included. However, there is an exception that if etcd server is configured to listen on default port of the scheme (:443 on https and :80 on http). It is descried in https://www.rfc-editor.org/rfc/rfc3986#section-3.2.3 and the proxy server should support it. /cc @menghanl for advice. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
For e2e test case, the |
backport etcd-io#14834 and etcd-io#16324 Signed-off-by: Chao Chen <[email protected]>
Replace #15131 with endpoints.Interpret returns Host:port as ServerName. It should also help #16290
After this change, each h2 request will be sent with the proper authority header value instead of only the first one out of three dialing endpoints. This should resolve the issue mentioned in #13192 (comment).
Note: client certificate validation on server name won't break because of grpc/grpc-go#3082
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.