Skip Menu |
 

This queue is for tickets about the Net-Stomp CPAN distribution.

Report information
The Basics
Id: 105500
Status: resolved
Priority: 0/
Queue: Net-Stomp

People
Owner: Nobody in particular
Requestors: dryapak [...] outlook.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.56



Subject: Reading a buffsize-sized frame
Date: Fri, 26 Jun 2015 13:39:14 +0300
To: "bug-Net-Stomp [...] rt.cpan.org" <bug-net-stomp [...] rt.cpan.org>
From: Dryapak Grigory <dryapak [...] outlook.com>
Download (untitled) / with headers
text/plain 729b
Hello, I think there's a bug in the _read_body function. I've found that after receiving a frame of exactly 8192 bytes (command + headers + body), the *next* received frame is damaged - it contains a ^@ (null byte) as the first character of $frame->command. If I change the bufsize parameter (it's 8192 by default), both frames are received correctly. Probably the client reads 8192 bytes that contain the entire frame (determined by the content-length header), but the null-byte trailer is left in socket. So, this line does nothing: https://github.com/dakkar/net-stomp/blob/1e20262665a3b2bca994241937ed2003346008c8/lib/Net/Stomp.pm#L451 ... and the null-byte is attached to the front of the next received frame.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.