[
https://issues.apache.org/jira/browse/QPID-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Kirilyuk updated QPID-8732:
----------------------------------
Summary: [Broker-J] UI "Download Content" downloads a few extra header
bytes (was: UI "Download Content" downloads a few extra header bytes)
> [Broker-J] 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-9.2.1, qpid-java-broker-10.0.1
> Environment: v9.2.1 on Redhat w/Java17
> v10.0.1 on MacOS w/Java17
> Reporter: Dan Langford
> Priority: Minor
> 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]
