Developing a new AMQP 0-9-1 client: table parsing fails #10914
-
Describe the bugWhen attempting to send the Header message property, using a short string as a value fails with the following traceback: The content header frame which caused the above error: Note that changing the value in the table to be a LongString, subsequently giving the following frame: Resolves this error and the message is parsed as expected. It's highly possible I have missed something from the documentation, but from the documentation here it appears that one should be able to use a short string. Reproduction steps
Expected behaviorShort strings should be able to be used as Header property values. Additional contextDisclaimer: This was behaviour I found when building out a client library. I may well have misread some documentation and if so, I apologise and feel free to close this issue! |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 5 replies
-
|
It would greatly assist us if you provide a complete, runnable code sample that we can use to reproduce this issue. |
Beta Was this translation helpful? Give feedback.
-
|
I've been scanning through the code, and am unfamiliar with erlang, however: rabbitmq-server/deps/rabbit_common/src/rabbit_misc.erl Lines 375 to 396 in 3486206 Does this imply that only long strings are supported as values (specifically line 390)? Does not affect me and I don't see that as an issue but would be great if the documentation matched that if so? |
Beta Was this translation helpful? Give feedback.
-
|
The code you are looking at is a table generator, not a parser. There are no meaningful benefits to using short strings. The AMQP 0-9-1 spec is frozen in time and not being worked on, so I'm not sure where we can document it, besides the errata, perhaps. For parsing, see |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
Of course, apologies, I'm working on building my own client so that may be difficult to share. I can try get it into working order and share it. However, after completing the connection process, opening a channel, and declaring a queue, |
Beta Was this translation helpful? Give feedback.
-
|
Given that it does not affect existing clients or every client manages to avoid it, the problem is more likely to be in your own code. @Sammo98 please provide a way to reproduce this using any existing mature client: Java, .NET, the Go client maintained by our team, Pika, Bunny, amqplib for Node, amqprs for Rust, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Also, it may be tempting to assume that the AMQP 0-9-1 parser ecosystem actually uses every type in practice, and that the spec is correct and complete but that is not the case. There are certain types that are used drastically more often than others, and there is an AMQP 0-9-1 errata document that reflects the actual state of the server and clients since about 2008-2009. |
Beta Was this translation helpful? Give feedback.
-
|
In the errata document, there is this note: so to avoid this conflict, the founders of RabbitMQ must have chosen to use long strings ( There isn't really a separation between "short" and "long" strings in Java, C#/F#, Python, and most programming languages. So this choice of using only long strings in attribute tables makes general sense. |
Beta Was this translation helpful? Give feedback.
-
|
A table of just one pair, like so: {
"abc": "abc"
}Can be produced like so (start a node with rabbit_binary_generator:generate_table(rabbit_misc:to_amqp_table([{<<"abc">>, longstr, <<"abc">>}])).
%% => <<3,97,98,99,83,0,0,0,3,97,98,99>>which matches the table part in the question. So the answer is: use long strings for argument tables. There are no benefits to using short strings, and the errata document provides a hint as to why short strings have been avoided from the early days: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this information Michael, very useful and appreciate the time you took to explain it. I of course have no issues using long strings over short strings (hopefully those 3 extra bytes aren't going to harm anyone), was just confused as to why one was accepted and the other not!
|
Beta Was this translation helpful? Give feedback.
-
|
Those docs are not for those who implement the protocol. They are for those who use RabbitMQ client libraries, which, as mentioned above, all use long strings internally. |
Beta Was this translation helpful? Give feedback.
A table of just one pair, like so:
{ "abc": "abc" }Can be produced like so (start a node with
RABBITMQ_ALLOW_INPUT=1env variable set, or userabbitmq-diagnostics remote_shell):which matches the table part in the question.
So the answer is: use long strings for argument tables. There are no benefits to using short strings, and the errata document provides a hint as to why short strings have been avoided from the early days: