[
https://issues.apache.org/jira/browse/PROTON-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115327#comment-18115327
]
ASF subversion and git services commented on PROTON-2967:
---------------------------------------------------------
Commit aaf4c2ce7669c19453bc09c8f49147b73ed37f5e in qpid-proton's branch
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=aaf4c2ce7 ]
PROTON-2967: Decode AMQP values iteratively rather than recursively
pn_decoder_decode() recursed once per level of nesting, so the C stack it
consumed grew with the nesting depth of the value being decoded.
Decode iteratively instead. The state a recursive decoder keeps in its stack
frames - how many children of the enclosing container are still to come, and,
for an array, the constructor its elements share - is now kept in the
container's own node, in the scratch space the encoder also uses. The tree
being built is therefore also the decoder's stack, so the only bound on
nesting is the node array: PNI_NID_MAX, and any limit set with
pn_data_set_decode_limits().
Every open node - list, map, array and described alike - carries a count of
the children still to be decoded, which lets a single loop close each node as
its last child arrives.
The AMQP standard is contradictory about whether described types
are allowed to be directly nested:
In the descriptive text for described format code it says "prmitive
format code" which would disallow a described type. The formal syntax
allows it, merely specifying "constructor". The section on transactions
requires the message body to the transaction coordinator to be an amqp
value (a described type) with a direct value of another described type
for declaring and discharging transactions.
So to sanity check incoming AMQP values we only allow a single directly
nested described type. This is all that is required per the standard,
and it's hard to see a valid use for more deeply nested described types.
Assisted-By: Claude Opus 5 <[email protected]>
> Decode AMQP values iteratively rather than recursively
> ------------------------------------------------------
>
> Key: PROTON-2967
> URL: https://issues.apache.org/jira/browse/PROTON-2967
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Priority: Major
> Fix For: proton-c-0.41.0
>
>
> Decode AMQP values iteratively: The state a recursive decoder keeps in its
> stack frames - how many children of the enclosing container are still to
> come, and, for an array, the constructor its elements share - can be kept in
> the container's own node, in the scratch space the encoder already uses.
> The tree being built is then also the decoder's stack, so the only bound on
> nesting is
> the node array: PNI_NID_MAX, and any limit set with
> pn_data_set_decode_limits().
> Every open node - list, map, array and described alike - carries a count of
> the children still to be decoded, which lets a single loop close each node as
> its last child arrives.
> Only accept a single directly nested described type and no more. That is all
> the standard requires (and then only in the case of transaction coordinator
> messages), and it is hard to see a valid use for more deeply nested described
> types.
> Restricted descriptors to scalar values only, which is no limitation in
> practice and keeps the descriptor path free of nesting.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
