You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unify the four resource-identifier gates behind one private helper so the order stops diverging #33
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 beforeURI.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.
Activity
docs: give every "tracked" deferral an issue a reader can follow
feat(core): metadata refresh on the verification path, and identifier…