fn decode_largest_object(bytes: &[u8]) -> FieldValueExpand description
Render a draft-16 LARGEST_OBJECT (0x09) parameter value: a Group and an Object, as two varints.
§Nothing has checked that the value is two varints
Drafts 17 and later give 0x09 a Location encoding: their decoders read the
two varints and re-serialise them into the stored value, so what reaches
their extractor is two varints by construction. Draft-16 has no such table.
0x09 is an odd Type, so KeyValuePair::decode keeps whatever
length-prefixed bytes arrived, and decode_parameters_in checks duplicates,
authorization tokens, varint value ranges and subscription filters — none of
which looks at 0x09. KNOWN_MESSAGE_PARAMETERS admits it and
check_parameter_scope permits it on SUBSCRIBE_OK, so a short SUBSCRIBE_OK
carrying 0x09 with an empty value reaches here.
An empty value fails the first read and a single 0x00 fails the second,
which is the nastier of the two: the first varint decodes cleanly and the
value looks well formed right up to the point where it is not.
§What a value it cannot read renders as
The raw bytes, as fields::params and this file’s own
auth_token_to_json_d16 do. Field extraction runs on a message that has
already decoded, so it has no refusal to give: what a peer sent is what
there is to show.