Tickets :: Comment on [#14201] Saving of Kolab XML objects with non-7bit elements fails

* Your Email Address
* Spam protection	Enter the letters below: .__ __.. ..__ .___ [__)(__ \| \|[__)[__ \| .__)\|__\|[__)[___
Comment	> Hi Michael, > > thanks for going through all my recent bug reports. I highly appreciate that. > >> Can you please give some more detail as to exactly what is failing >> with non 7-bit characters? > > I just realize, I was a bit unclear about the history of debugging > this issue with all my previous posts on this bug report. Sorry for > that. > > In the course of things, my first observation was: > > o disable Horde caching > o Create an event (or task, or memo, ...) without umlauts > o Save the event (-> ok) (here as quoted-printable attachment) > o Edit the event, add an umlaut into the title or location or whereever. > o Save the event (-> event vanishes, at the latest when logging out > and in again) > > Alternatively: > > o disable Horde caching > o Create an event, add an umlaut into the title or location or whereever. > o Save the event (-> event vanishes, at the latest when logging out > and in again) > > The above got fixed by the patch provided in #14199. With #14199 > fixed, I now can see Kolab groupware objects containing Umlauts. > Things looked normal again with Horde caching enabled and disabled. > > THEN... (coming to this bug)... > > The next observation was: > > o Edit an event already containing umlauts (that is now visible, > after #14199 has been fixed). > Double check that this event is stored as base64 transfer-encoded > Kolab XML attachment. > o It doesn't matter if you add another umlaut or remove umlauts or > whatever. > o Save the event (or task, or note, ...) -> results in the below > browser notification: > > """ > Failed writing the Kolab object: Failed parsing Kolab object input > data of type string! Input was: > Æioz»"¢}tzw(v)àQ1\|z÷§¶÷«²*'×K¢wºå?... [shortened to 50 characters] > """ >> With the "double decoding" patch applied, I don't have any issues >> when saving/editing/syncing data containing 8bit data (and thus >> base64 encoded in the imap message). > > The error does not get raised in actually saving the new object. It > some gets raised by processing the "previous" object (which is not > really handled in the Kolab_Storage code, at all). > > The issue got also observed by Jens and has been reported as #13865. > > Jens tested my proposed (work-around) patch and reported success, as > well. See communication history of #13865. > > Hope this extra information helps, > Mike
Attachment
Watch this ticket

Saved Queries