|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:... and the null-byte is attached to the front of the next received frame.