6.0.0-beta1
7/7/25

[#8534] Net_IMSP receiveStringLiteral failing for long (+10K) literals
Summary Net_IMSP receiveStringLiteral failing for long (+10K) literals
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State Resolved
Priority 2. Medium
Owners mrubinsk (at) horde (dot) org
Requester noah (at) lsit (dot) ucsb (dot) edu
Created 08/27/2009 (5793 days ago)
Due
Updated 10/01/2009 (5758 days ago)
Assigned 08/28/2009 (5792 days ago)
Resolved 10/01/2009 (5758 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch Yes

History
10/01/2009 11:54:05 PM Michael Rubinsky Comment #3
State ⇒ Resolved
Reply to this comment
Committed and merged to FW_3.



Thanks for all the well thought out and explained bug reports!
10/01/2009 11:50:16 PM CVS Commit Comment #2 Reply to this comment
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
08/28/2009 08:57:50 AM Jan Schneider State ⇒ Assigned
Assigned to Michael Rubinsky
 
08/27/2009 11:47:00 PM noah (at) lsit (dot) ucsb (dot) edu Comment #1
Priority ⇒ 2. Medium
New Attachment: IMSP-receive-long-string-literal.patch Download
Patch ⇒ Yes
Milestone ⇒
Summary ⇒ Net_IMSP receiveStringLiteral failing for long (+10K) literals
Type ⇒ Bug
State ⇒ Unconfirmed
Queue ⇒ Horde Framework Packages
Reply to this comment
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.

Saved Queries