On Wed, 2015-06-10 at 16:32 +0100, Gordon Sim wrote:
> On 06/10/2015 04:01 PM, aconway wrote:
> > On Tue, 2015-06-09 at 19:54 +0100, Gordon Sim wrote:
> > > On 06/09/2015 06:40 PM, logty wrote:
> > > > When I run the client I get:
> > > >
> > > > [0x5351db0]:0 <- @transfer(20) [handle=0, delivery-id=0,
> > > > delivery
> > > > -tag=b"",
> > > > message-format=0, settled=true, more=true] (16363)
> > > > "\x00Sp\xc0\x07\x05B..."
> > >
> > > My guess would be that it is the delivery tag being null (or
> > > empty,
> > > can't tell which) that is the problem. From the spec:
> > >
> > > "This field MUST be specified for the first transfer of
> > > a multi-transfer message and can only be omitted for
> > > continuation transfers." [section 2.7.5]
> > >
> > > So I think that whatever is sending that frame has a bug. Proton
> > > -c
> > > has a
> > > bug too of course, since it shouldn't segfault but should close
> > > the
> > > connection with a framing-error or similar.
> > It says the field must be specified, it does not say it must not be
> > an
> > empty binary value. Is the field really missing or is proton
> > choking on
> > a 0-length delivery tag?
> I'm not sure the distinction between null and an empty value is very
> useful here. The intent is that the delivery is clearly identified. I
> would argue that a 'zero byte identifier' doesn't meet the spirit of
> law there.
I disagree. An empty string is a perfectly legal value for a string. If
the spec wants to assign special meaning to particular values of a
property that needs to be stated. Of course, like you, I personally
would not use an empty string as an identifier but as an implementor of
an inter-operable spec I think we have to take the large view: *any*
legal value of a parameter has to be considered equal unless the spec
clearly states otherwise.
> > It shouldn't, which might explain why rabbit is OK with
> > it.
> I don't think RabbitMQ is ever seeing that frame. I believe that
> is emitted by ApolloMQ to the receiving client.
Rabbit, Apollo, whoever. If somebody is using the empty string as a
delivery tag and the spec does not clearly state "you must never use
the empty string as a delivery tag" then we should accept it.
> I agree that proton should not choke on a zero byte delivery tag (or
> indeed on a non-existent delivery tag). But I do think it's a bug to
> send such a frame.
Quote me the spec, this is a mater of law not opinion ;)