Skip to content

any: read a type URL without a '/' as a bare message name - #692

Merged
iainmcgin merged 1 commit into
mainfrom
any-bare-type-name
Oct 10, 2026
Merged

iainmcgin merged 1 commit into
mainfrom
any-bare-type-name

Conversation

@iainmcgin

Copy link
Copy Markdown
Collaborator

A google.protobuf.Any whose type_url has no / was resolved by DynamicMessage and rejected by the generated Any JSON parser. any.proto requires the /; protobuf-go and Python read a bare full name anyway, and C++ and Java reject it.

  • The generated Any JSON parser accepts {"@type": "pkg.Message", ...} when the type registry has a JSON entry for pkg.Message. Such an Any is now written expanded; it was written as base64 under value, which the same parser rejected. A payload that does not decode as that message now fails to serialize.
  • A bare name that does not resolve is a parse error and never takes the base64 form. The conformance test AnyWktRepresentationWithBadType requires that. The serializer still writes the base64 form for such an Any, so it does not round-trip.
  • AnyRegistry::lookup and TypeRegistry::json_any_by_url find an entry by a bare name, and an entry registered under a bare name is found under any URL prefix.
  • Any::type_name, is_message and unpack_message (unreleased, any: add typed pack and unpack helpers #499) read a URL without a / as the name.
  • JsonParseOptions::strict_any_type_urls and DynamicMessageSeed::strict_any_type_urls reject an @type without a /, at any depth of Any in Any. The reflective seeds pass both parse options down in one ParseFlags value, which is most of the change in reflect/json.rs.
let opts = JsonParseOptions::new().strict_any_type_urls(true);
let msg = with_json_parse_options(&opts, || serde_json::from_str::<MyMsg>(json))?;

Serialization, DynamicMessage::unpack_any and Any::type_name take no options and resolve a bare name. Text format does not resolve a bare name, because [pkg.Message] { ... } is the syntax of an extension field.

The error for an empty @type, or one ending in /, now reads @type "..." is not a valid type URL: it names no type.

The changelog entry is Changed. #485, which changed the same output for a URL with an unregistered prefix, is filed under Breaking changes; 0.9.2 could not parse a bare @type at all, so less depends on the old output here.

Supersedes #524, which made the reflective path reject a bare name.

A `google.protobuf.Any` whose `type_url` has no `/` was resolved by
`DynamicMessage` and rejected by the generated `Any` JSON parser.
`any.proto` requires the `/`; protobuf-go and Python read a bare full
name anyway, and C++ and Java reject it.

Both JSON parsers now accept a bare name that resolves. The generated
parser reads `{"@type": "pkg.Message", ...}` when the type registry has
a JSON entry for `pkg.Message`, and the serializer writes such an `Any`
expanded. A bare name that does not resolve stays a parse error and is
never read in the base64 form, which the conformance test
`AnyWktRepresentationWithBadType` requires. `Any::type_name`,
`is_message` and `unpack_message` read a URL without a `/` as the name,
and `AnyRegistry::lookup` matches one by name.

`JsonParseOptions::strict_any_type_urls` and
`DynamicMessageSeed::strict_any_type_urls` reject an `@type` without a
`/` when parsing. The reflective seeds carry the two parse options in
one `ParseFlags` value.

Text format does not resolve a bare name, because `[pkg.Message] { }`
is the syntax of an extension field.
@github-actions

Copy link
Copy Markdown

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@iainmcgin
iainmcgin marked this pull request as ready for review October 10, 2026 18:25
@iainmcgin
iainmcgin enabled auto-merge October 10, 2026 18:26
@iainmcgin
iainmcgin requested a review from rpb-ant October 10, 2026 18:26
@iainmcgin
iainmcgin added this pull request to the merge queue Oct 10, 2026
Merged via the queue into main with commit c5528ac Oct 10, 2026
11 checks passed
@iainmcgin
iainmcgin deleted the any-bare-type-name branch October 10, 2026 20:36
@github-actions github-actions Bot locked and limited conversation to collaborators Oct 10, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants