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

* Your Email Address
* Spam protection	Enter the letters below: . .. ,. ,\ / __. \|\ \| \./ \./ >< (__ \| \\| \| \| / \.__)
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.
Attachment
Watch this ticket

Saved Queries