Fri, 10 Apr 2026 09:21:08 +0000 https://bugs.horde.org/ticket/8534 Net_IMSP receiveStringLiteral failing for long (+10K) literals 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. Thu, 27 Aug 2009 23:47:00 +0000 https://bugs.horde.org/ticket/8534#t55566 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 Thu, 01 Oct 2009 23:50:16 +0000 https://bugs.horde.org/ticket/8534#t56137 Committed and merged to FW_3. Thanks for all the well thought out and explained bug reports! Thu, 01 Oct 2009 23:54:05 +0000 https://bugs.horde.org/ticket/8534#t56138