[rabbitmq-discuss] RabbitMQ 3.3.0 .NET producer/STOMP consumer: bad content-length possible?

[Michael Justin]

Hello,

a user of my (Delphi/Free Pascal) STOMP client for RabbitMQ reported 
random errors where the client library did find a valid STOMP frame in 
the incoming socket data.

The STOMP library reads the number of bytes found in the content-length 
header from the socket. A wrong content-length header value would cause 
the client to read only a partial body, or past the end of the frame and 
- if there are more frames in the socket - into the next frame. (As 
STOMP frames must have a terminating NUL byte, this can be detected by 
the client).

I tried to exchange messages with bad content-length values between 
STOMP clients. But the broker (3.3.0) successfully detects protocol 
errors, so the consumer will not receive the 'bad' message.

Could it be that the reason is not a STOMP client sending invalid 
frames, but a special case inside the broker, caused by data sent from a 
different (non-STOMP) client?

I asked the user which client library is used on the message producer 
side. The environment is:
* RabbitMQ Broker version 3.1.5 running on Windows Server 2008 R2 
Standard, Service Pack 1
* The messages are sent from a C# .NET application using the RabbitMQ 
.NET Client Library version 3.3.0

Suggestions for test cases or other potential causes are very welcome.

Regards
-- 
Michael Justin