[
https://issues.apache.org/jira/browse/QPID-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103287#comment-16103287
]
ASF subversion and git services commented on QPID-7434:
-------------------------------------------------------
Commit 9d8a05cd72e4877a217024f3df5e40a8f9c45b37 in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=9d8a05c ]
QPID-7434: Verify that illegal key or values are not included into
application-properties on conversion from 0-8 into 1.0
> Mature the AMQP message conversion layer (headers and content)
> --------------------------------------------------------------
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message
> are not converted with complete fidelity (particularly in the treatment of
> application headers), and where complete fidelity cannot be acheived we need
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were
> complex types (e.g. map). AMQP 1.0 disallows this. What should the
> behaviour be? Should the header be dropped?
> Another instance is the length and constituency of the keys of application
> headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP
> has supports longer strings. Also AMQP 0-9 says further restricts the key to
> be formed like a Java identifier.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
