Skip to content
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

XdsNameResolver and XdsServerWrapper don't check listener type #11737

Open
ejona86 opened this issue Dec 10, 2024 · 1 comment
Open

XdsNameResolver and XdsServerWrapper don't check listener type #11737

ejona86 opened this issue Dec 10, 2024 · 1 comment
Labels
Milestone

Comments

@ejona86
Copy link
Member

ejona86 commented Dec 10, 2024

Our resource parsing supports two listener types (I'm not confident enough validation is happening here):

if (listener.hasApiListener()) {
return processClientSideListener(listener, args);
} else {
return processServerSideListener(listener, args);
}

But XdsNameResolver and XdsServerWrapper don't check that they got the right type. No changes were made to XdsNameResolver when non-API listener type was allowed, so I doubt the logic exists but I'm just not seeing it.

I also don't see XdsServerWrapper call address(), so it appears it is not follow gRFC A36.

The XdsServer must be "not serving" if the address does not match.

@ejona86 ejona86 added the bug label Dec 10, 2024
@ejona86 ejona86 added this to the Next milestone Dec 10, 2024
@ejona86
Copy link
Member Author

ejona86 commented Dec 16, 2024

Looks like the client receiving a socket listener will throw a NullPointerException, because httpConnectionManager() is null and instead listener() is set:

HttpConnectionManager httpConnectionManager = update.httpConnectionManager();
List<VirtualHost> virtualHosts = httpConnectionManager.virtualHosts();
String rdsName = httpConnectionManager.rdsName();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant