grpc: gRPC Name Resolution docs invalid example template string

The template for the URL is given as dns:[//authority/]host[:port] - however, in reality it’s dns:[//authority]/host[:port] - because the /host is actually treated as URL path part internally, see e.g. https://github.com/grpc/grpc-java/blob/master/core/src/main/java/io/grpc/internal/DnsNameResolverProvider.java#L56 :

Preconditions.checkArgument(targetPath.startsWith("/"),
          "the path component (%s) of the target (%s) must start with '/'", targetPath, targetUri);

Experiments with grpc-java show that both dns:///foobar and dns:/foobar are OK, while dns:foobar is not, which confirms the above (i.e. doc mistake).

About this issue

Original URL
State: closed
Created 6 months ago
Comments: 15 (8 by maintainers)

Most upvoted comments

To be clear, I am not saying that we should support dns:name format only because it’s documented in RFC-4501; I am saying that we should support it because it’s a form that users should be able to expect to work, and I was citing the fact that that form is supported in RFC-4501 as a justification for that assertion.

I do not think the general statement that we support RFC-4501 is correct or useful, since we clearly do not and will not support all of the forms documented there.

markdroth on Jan 16, 2024

@ejona86 I don’t think it makes any sense at all to not support dns:host. If you support dns:/host but not dns:host, you are saying that the slash is required in the path, which makes no sense, since the slash is not useful to begin with. The only reason it’s ever there is because it’s a required separator in the case where the URI includes an authority. I think it’s very clearly an optional part that should be ignored if present but not required.

It’s worth noting that while RFC-3986 allows both dns:name and dns:/name, RFC-4501 says that the spec is dns:[//authority/]name, which means that dns:name is valid but dns:/name is not. I think it’s clear that dns:/name is a weird edge case that C-core happens to accept but that is arguably not intended. I don’t think there is any reasonable reading of these RFCs that says that dns:name is not okay.

I think our spec is correct as-is, and I consider it a bug that grpc-java does not support dns:name.

@FyiurAmron I don’t see anything in https://grpc.io/docs/guides/custom-name-resolution/ that conflicts with the naming spec.

markdroth on Jan 12, 2024

I thought it was saying that dns:/host was okay but dns:host was not, whereas it’s actually saying the opposite.

No, it is dns:/host works, but not dns:host. Java has never had any plan to support the dns:host. We accept C does it and Java doesn’t and users are best off using dns:///host or dns:/host. The documentation referenced was written in a weak way on purpose because we didn’t agree.

ejona86 on Jan 12, 2024