You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by aconway <ac...@redhat.com> on 2015/09/08 23:36:39 UTC
Bug in proton interop suite??
I'm doing some interop work on the go binding, and I see something
strange in the 'message.amqp' file in tests/interop. The message body
is encoded as:
0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f
^ AMQP value section
^Binary
^7 bytes
^String
^5 bytes
h e l l o
In other words there's an AMQP-encoded string *inside* an AMQP encoded
binary. Looking at the python code that generated this message I would
expect it to be an AMQP 5 byte binary value "hello". I think the intent
was for it to be a string, but in python plain "hello" is binary you
need to say u"hello" to get a string. However I can't see any reason
why there would be a string *inside* a binary. Anyone have a clue
what's going on here?
Cheers,
Alan.
Re: Bug in proton interop suite??
Posted by aconway <ac...@redhat.com>.
On Wed, 2015-09-09 at 08:06 -0400, Chuck Rolke wrote:
> https://issues.apache.org/jira/browse/PROTON-308
>
> More documentation required...
That's not it. The python code that generates the message does indeed
use "hello" so I would expect a vbin containing the bytes "hello", but
what I see is a vbin containing *the AMQP string encoding* of the
string hello - i.e. a 7 byte binary sequence with the typecode for AMQP
string + the length 5 + the bytes "hello"
>
> ----- Original Message -----
> > From: "aconway" <ac...@redhat.com>
> > To: "proton" <pr...@qpid.apache.org>
> > Sent: Tuesday, September 8, 2015 5:36:39 PM
> > Subject: Bug in proton interop suite??
> >
> > I'm doing some interop work on the go binding, and I see something
> > strange in the 'message.amqp' file in tests/interop. The message
> > body
> > is encoded as:
> >
> > 0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f
> > ^ AMQP value section
> > ^Binary
> > ^7 bytes
> > ^String
> > ^5 bytes
> > h e l l o
> >
> > In other words there's an AMQP-encoded string *inside* an AMQP
> > encoded
> > binary. Looking at the python code that generated this message I
> > would
> > expect it to be an AMQP 5 byte binary value "hello". I think the
> > intent
> > was for it to be a string, but in python plain "hello" is binary
> > you
> > need to say u"hello" to get a string. However I can't see any
> > reason
> > why there would be a string *inside* a binary. Anyone have a clue
> > what's going on here?
> >
> > Cheers,
> > Alan.
> >
> >
Re: Bug in proton interop suite??
Posted by Ken Giusti <kg...@redhat.com>.
Alan - can you try the same test under Python3 and grab the decoding?
Python3 will (should) always encode string literals as AMQP UTF strings.
----- Original Message -----
> From: "Chuck Rolke" <cr...@redhat.com>
> To: proton@qpid.apache.org
> Sent: Wednesday, September 9, 2015 8:06:38 AM
> Subject: Re: Bug in proton interop suite??
>
> https://issues.apache.org/jira/browse/PROTON-308
>
> More documentation required...
>
> ----- Original Message -----
> > From: "aconway" <ac...@redhat.com>
> > To: "proton" <pr...@qpid.apache.org>
> > Sent: Tuesday, September 8, 2015 5:36:39 PM
> > Subject: Bug in proton interop suite??
> >
> > I'm doing some interop work on the go binding, and I see something
> > strange in the 'message.amqp' file in tests/interop. The message body
> > is encoded as:
> >
> > 0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f
> > ^ AMQP value section
> > ^Binary
> > ^7 bytes
> > ^String
> > ^5 bytes
> > h e l l o
> >
> > In other words there's an AMQP-encoded string *inside* an AMQP encoded
> > binary. Looking at the python code that generated this message I would
> > expect it to be an AMQP 5 byte binary value "hello". I think the intent
> > was for it to be a string, but in python plain "hello" is binary you
> > need to say u"hello" to get a string. However I can't see any reason
> > why there would be a string *inside* a binary. Anyone have a clue
> > what's going on here?
> >
> > Cheers,
> > Alan.
> >
> >
>
--
-K
Re: Bug in proton interop suite??
Posted by Chuck Rolke <cr...@redhat.com>.
https://issues.apache.org/jira/browse/PROTON-308
More documentation required...
----- Original Message -----
> From: "aconway" <ac...@redhat.com>
> To: "proton" <pr...@qpid.apache.org>
> Sent: Tuesday, September 8, 2015 5:36:39 PM
> Subject: Bug in proton interop suite??
>
> I'm doing some interop work on the go binding, and I see something
> strange in the 'message.amqp' file in tests/interop. The message body
> is encoded as:
>
> 0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f
> ^ AMQP value section
> ^Binary
> ^7 bytes
> ^String
> ^5 bytes
> h e l l o
>
> In other words there's an AMQP-encoded string *inside* an AMQP encoded
> binary. Looking at the python code that generated this message I would
> expect it to be an AMQP 5 byte binary value "hello". I think the intent
> was for it to be a string, but in python plain "hello" is binary you
> need to say u"hello" to get a string. However I can't see any reason
> why there would be a string *inside* a binary. Anyone have a clue
> what's going on here?
>
> Cheers,
> Alan.
>
>
Re: Bug in proton interop suite??
Posted by Ted Ross <tr...@redhat.com>.
I don't think this is a valid data sequence. Literally, it is a binary
sequence of seven octets where the internal encoding of a string is
coincidental. Binary is not a compound type and does not contain
sub-fields.
-Ted
On 09/08/2015 05:36 PM, aconway wrote:
> I'm doing some interop work on the go binding, and I see something
> strange in the 'message.amqp' file in tests/interop. The message body
> is encoded as:
>
> 0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f
> ^ AMQP value section
> ^Binary
> ^7 bytes
> ^String
> ^5 bytes
> h e l l o
>
> In other words there's an AMQP-encoded string *inside* an AMQP encoded
> binary. Looking at the python code that generated this message I would
> expect it to be an AMQP 5 byte binary value "hello". I think the intent
> was for it to be a string, but in python plain "hello" is binary you
> need to say u"hello" to get a string. However I can't see any reason
> why there would be a string *inside* a binary. Anyone have a clue
> what's going on here?
>
> Cheers,
> Alan.
>