bug in PHP API, with fix attached

[Tim Starling]

This is a multi-part message in MIME format.
--------------000301020302000209050703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



The PHP API _load_items() function reads in blocks of 1024 bytes. By
coincidence, I was testing with a message that caused the "\r\nEND\r\n"
terminator to fall across a 1024 byte boundary. Usually this is no big
deal, but in my case, the part in the first block was "\r\nEND" and in the
second block it was just "\r\n". Any empty line is skipped by a continue
statement without any further processing, leading to another call to
socket_read() and hence causing the client to block indefinitely.

The patch is to check if it is near the end, and to read slightly more
than 1024 bytes if it is.

Tim Starling
Wikipedia http://en.wikipedia.org/
 <http://en.wikipedia.org/>


--------------000301020302000209050703
Content-Type: text/plain;
 name="mc_phpapi_block_boundary.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="mc_phpapi_block_boundary.diff"

Index: MemCachedClient.inc.php
===================================================================
RCS file: /cvsroot/wikipedia/phase3/includes/MemCachedClient.inc.php,v
retrieving revision 1.3
diff -r1.3 MemCachedClient.inc.php
1062a1063,1072
> 			// if we're almost at the end, read the rest, so 
> 			// that we don't corrupt the \r\nEND\r\n
> 			if ($bytes_read >= $len)
> 			{
> 				$lastbit = socket_read($sock, $len - $bytes_read + 7, PHP_BINARY_READ);
> 				$line .= $lastbit;
> 				$buf .= $lastbit;
> 				$bytes_read += strlen($lastbit);
> 			}
> 
1143c1153
< ?>
\ No newline at end of file
---
> ?>
--------------000301020302000209050703--