Committed and merged to FW_3.



Thanks for all the well thought out and explained bug reports!

Changes have been made in CVS for this ticket:

Don't assume we can read the entire stream in one go.
Bug: 8534
Submitted by: noah (at) lsit (dot) ucsb (dot) edu
http://cvs.horde.org/diff.php/framework/Net_IMSP/IMSP.php?rt=horde&r1=1.43&r2=1.44&ty=u

We have been having a problem with turba using IMSP backends. I traced 
one of our problems back to the receiveStringLiteral function in 
IMSP.php, being called upon to receive a {11122} length email field. 
It seems that the function calls fread only once, which is problematic 
in light of this from php.net:

Reading stops as soon as one of the following conditions is met:

        •        length bytes have been read

        •        EOF (end of file) is reached

        •        a packet becomes available (for network streams)

        •        8192 bytes have been read (after opening userspace stream)



In my testing with an 11122 octet literal, I was seeing actual lengths 
read between 9500 and the full 11122, suggesting to me that the 3rd 
condition in the list above is relevant. At the 11122 level, getting 
the entire thing in a single fread is still a common occurence, moreso 
than missing, but not by much. Seems like with much larger values the 
success of the function would taper off.



As far as symptoms go, while rare, this failure can be bad, as it can 
leave the IMSP connection in an inconsistent state, causing subsequent 
calls to fail, and sometimes enter endless loops (w/ error level log 
messages in the loop) waiting for a particular return value.



I have provided a patch with a mostly replaced receiveStringLiteral 
function that calls fread in a do {} while loop until the requested 
number of octets is read.



The new function keeps track of $length received using strlen.  It 
works well on our system, tested with ASCII, ISO-8859-1, and UTF-8. I 
was concerned about what could happen with mbstring.func_overload = 2, 
which we don't normally use, but  enabling it didn't seem to cause 
problems.



Also, related to bug 8533, in this patch I've removed the trim() 
around the fread. It doesn't seem right to strip whitespace from a 
value that's supposed to be read as a literal, with a specific number 
of byte octets. The presence of trim there breaks browsing IMSP abooks 
containing contacts with extraneous leading/trailing space in the 
contact name, especially if the name also has multi-byte characters 
(assuring it will be transferred as a literal by the IMSP server).



Patch against HEAD provided.