Dan Langford created QPID-8732:
----------------------------------
Summary: UI "Download Content" downloads a few extra header bytes
Key: QPID-8732
URL: https://issues.apache.org/jira/browse/QPID-8732
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-10.0.1, qpid-java-broker-9.2.1
Environment: v9.2.1 on Redhat w/Java17
v10.0.1 on MacOS w/Java17
Reporter: Dan Langford
Attachments: test_msg000000001, testhex.png
in the management ui
if I navigate to a queue, to message, view a message, then click "Download
Content"
we get MORE bytes then was actually sent as the content of the message. Here is
how I sent a message in java
{{ var ackType = CLIENT_ACKNOWLEDGE;}}
{{ var ctx = cf.createContext(ackType);}}
{{ var testQ = ctx.createQueue("test");}}
{{ ctx.createProducer().send(testQ, "this is a test message");}}
and what I receive via JMS is accurate but what I received from the UI is:
Sw°this is a test message
in hex
005377A1 16746869 73206973 20612074 65737420 6D657373 616765
(see attachments)
here are some notes I collected from when my team was trying to change our
downloader from JMS to the HTTP api:
{quote}some sample data:
005375B0 000001C0 30304750
005377B1 000003C9 7B225265
005375B0 00000817 3C3F786D
005375B0 00070AA3 41303030
005375A0 905B7B22 64617461
ok i think the first byte is null 0x00 and the next byte is 0x53 which means
"read 1 more byte" (1.6.6).
so this byte is the type like 0x75 or 0x77 (for our usage since we dont really
use Sequence or Footer). 0x75=binary and 0x77=amqp value (usually String for
us) (3.2.x)
the next byte will generally be one of 0xA0 0xB0 0xA1 0xB1 in which the 0 means
"binary" and the 1 means "string" but more importantly the A means "1 byte
needed for then length" and the B means "4 bytes needed for the length" (1.6.19
& 1.6.20)
and then after those length bytes the rest of the payload is the data
(referencing amqp-core-complete-v1.0.pdf)
---
here is a naive shortcut
(note i switch to dec, sorry)
if the 4th byte is is <=175 then the first 5 bytes can be dropped
if the 4th byte is >=176 then the first 8 bytes can be dropped
though it might be better to look at the 4th byte for one of {{0xA0}} {{0xB0}}
{{0xA1}} {{0xB1}} and error if the 4th byte is different so we can code for it
{quote}
point is I doing think that this is the type of headache you are expecting
users to go through when consuming the HTTP API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
