The four resource-identifier gates — fragment, query grammar, scheme, userinfo — run in the same set at every boundary but not in the same order.
| site |
order |
AuthplaneResource constructor |
fragment, query, scheme, userinfo |
AuthplaneClient.resource(...) |
fragment, query, scheme, userinfo |
ProtectedResourceMetadata.Builder#build() |
fragment, query, then scheme, userinfo |
ProtectedResourceMetadata.wellKnownUrl(String) |
fragment, scheme, userinfo, query |
An identifier that violates two gates at once — a query outside the RFC 3986 §3.4 grammar and a userinfo component, say — is reported for the query by every constructor and for the userinfo by wellKnownUrl. Both reject; only the message differs, so this is message quality rather than correctness.
Why close it rather than document it
It has been documented twice and both descriptions were wrong. The requireNoUserinfo javadoc said it runs "last of the four" (true at three sites), and the changelog said wellKnownUrl "enforces the same four gates as the constructors" (true of the set, not the order). Both now describe the divergence instead, which means there are three separate explanations of an inconsistency in the tree rather than no inconsistency.
The orders drifted because the gates were added at different times, each landing at whichever sites the change in hand touched.
Scope
One private requireIdentifier(String) running all four in a fixed order, called by all four sites. Two things to preserve:
wellKnownUrl runs its gates before URI.create, so an identifier that is both malformed and fragment-bearing is reported for the fragment rather than as a wrapped URISyntaxException.requireDerivable is not one of the four and stays where it is — it answers a different question, and its position relative to the fragment gate is load-bearing for the same message-quality reason.
Worth doing before #29, which adds two more axes and would otherwise be four edits instead of one.
The four resource-identifier gates — fragment, query grammar, scheme, userinfo — run in the same set at every boundary but not in the same order.
AuthplaneResourceconstructorAuthplaneClient.resource(...)ProtectedResourceMetadata.Builder#build()ProtectedResourceMetadata.wellKnownUrl(String)An identifier that violates two gates at once — a query outside the RFC 3986 §3.4 grammar and a userinfo component, say — is reported for the query by every constructor and for the userinfo by
wellKnownUrl. Both reject; only the message differs, so this is message quality rather than correctness.Why close it rather than document it
It has been documented twice and both descriptions were wrong. The
requireNoUserinfojavadoc said it runs "last of the four" (true at three sites), and the changelog saidwellKnownUrl"enforces the same four gates as the constructors" (true of the set, not the order). Both now describe the divergence instead, which means there are three separate explanations of an inconsistency in the tree rather than no inconsistency.The orders drifted because the gates were added at different times, each landing at whichever sites the change in hand touched.
Scope
One private
requireIdentifier(String)running all four in a fixed order, called by all four sites. Two things to preserve:wellKnownUrlruns its gates beforeURI.create, so an identifier that is both malformed and fragment-bearing is reported for the fragment rather than as a wrappedURISyntaxException.requireDerivableis not one of the four and stays where it is — it answers a different question, and its position relative to the fragment gate is load-bearing for the same message-quality reason.Worth doing before #29, which adds two more axes and would otherwise be four edits instead of one.