api: Turn on RFC 3986 parsing by default and update javadoc.#12764
Open
jdcormie wants to merge 1 commit into
Open
api: Turn on RFC 3986 parsing by default and update javadoc.#12764jdcormie wants to merge 1 commit into
jdcormie wants to merge 1 commit into
Conversation
4ee1db1 to
b83c409
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR enables RFC 3986 target parsing by default and updates public API Javadoc to describe RFC 3986 URIs (instead of the legacy java.net.URI hierarchical/opaque behavior), including new guidance about ambiguity when using authority-string targets.
Changes:
- Flip
GRPC_ENABLE_RFC3986_URISdefault totrue. - Update
ManagedChannelBuilder.forTarget()andGrpc.newChannelBuilder()Javadoc to describe RFC 3986 URI targets and authority-string conversion. - Add Javadoc discussion and examples highlighting ambiguity for targets like
foo:8080.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| api/src/main/java/io/grpc/ManagedChannelBuilder.java | Updates forTarget() Javadoc for RFC 3986 parsing and ambiguity guidance. |
| api/src/main/java/io/grpc/Grpc.java | Updates newChannelBuilder() Javadoc to match RFC 3986 parsing and ambiguity guidance. |
| api/src/main/java/io/grpc/FeatureFlags.java | Turns RFC 3986 parsing on by default via feature flag default change. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
d302879 to
2553260
Compare
Removed the "NameResolver-compliant" terminology because it's no longer needed. All RFC 3986 URIs are absolute in the sense that have a scheme (URI != "URI-reference"). RFC 3986 also does away with the hierarchical vs opaque distinction. All URIs now have a hierarchy of components (scheme, authority, path, query and fragment) it's just that some components can be absent and/or the empty string. Added discussion of ambiguity which is technically new with the RFC 3986 change. If you believed the current javadoc, a target like foo:8888 didn't used to be ambiguous because it is not a "valid NameResolver- compliant" URI -- the path doesn't start with / and so java.net.URI considers it opaque, not hierarchical as required. Fortunately (???) ManagedChannelImplBuilder never enforced the !isOpaque() requirement mentioned in the javadoc and so this ambiguity isn't actually new in practice. gRPC C++ also appears to suffer from the same problem.
2553260 to
303b550
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removed the "NameResolver-compliant" terminology because it's no longer
needed. All RFC 3986 URIs are absolute in the sense that have a scheme
(URI != "URI-reference"). RFC 3986 also does away with the hierarchical
vs opaque distinction. All URIs now have a hierarchy of components
(scheme, authority, path, query and fragment) it's just that some components
can be absent and/or the empty string.
Added discussion of ambiguity which is technically new with the RFC 3986
change. If you believed the current javadoc, a target like foo:8888
didn't used to be ambiguous because it is not a "valid NameResolver-
compliant" URI -- the path doesn't start with / and so java.net.URI
considers it opaque, not hierarchical as required. Fortunately (???)
ManagedChannelImplBuilder never enforced the !isOpaque() requirement
mentioned in the javadoc and so this ambiguity isn't actually new in
practice. gRPC C++ also appears to suffer from the same problem.
Will merge in sync with CL/888346527.