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 
> the 
> 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 
> frame 
> 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 ;)


Reply via email to