| 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> |
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.