[Tickets #8534] Net_IMSP receiveStringLiteral failing for long (+10K) literals

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8534
------------------------------------------------------------------------------
  Ticket             | 8534
  Created By         | noah at lsit.ucsb.edu
  Summary            | Net_IMSP receiveStringLiteral failing for long (+10K)
                     | literals
  Queue              | Horde Framework Packages
  Version            | HEAD
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             |
+New Attachment     | IMSP-receive-long-string-literal.patch
------------------------------------------------------------------------------


noah at lsit.ucsb.edu (2009-08-27 19:47) wrote:

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, caus
 ing 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.