Tickets :: Comment on [#1410] Message with 8 bit characters incorrectly shown, if message display refreshed

* Your Email Address
* Spam protection	Enter the letters below: .__ .__ . .. .__. \| \[__)\| \|\| \| \| \|__/\| \|__\|\|___\|__\
Comment	> I don't know what else to say. All the sample messages work > perfectly for me. I can switch between limited/all headers all day > long on a q-p or base64 message with iso-8859-1 charset and it > renders perfectly now. I can reply to this message and the body text > appears without error in the reply window. Removing the code from my > patch reverts the behavior to the old (broken) way. Everyone has > logged out, applied the patch, cleared the Horde cache, and updated > the framework? Also, if using a PHP cache, this cache needs to be > cleaned out also/ Because (obviously) I can't do anymore work on > this bug since it isn't broken for me. > > > > If someone else wants to play around, I can tell you this much > information. The cached object must contain the pristine, original > MIME_Message object. Previously, in PHP5, the MIME-Message object > that was being cached contained body text that had been converted, > etc. during the previous pageload. Thus, when the body parts were > being reloaded into the MIME_Message object the next page load, these > MIME_Parts are already marked as being converted from the original > content-encoding so no additional decoding was done. The solution - > keep a copy of the original MIME_Message object in the MIME_Contents > object until the MIME_Contents object is ready to be cached, then > replace the "dirty" MIME_Message object with the pristine object . > > > > You don't want to keep MIME_Message cached across page loads because > it is possible that the body text will be changed (i.e. if you want > to view images in an HTML part) so the MIME_Message object must be > rebuilt every page load.
Attachment
Watch this ticket

Saved Queries