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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/14201
------------------------------------------------------------------------------
  Ticket             | 14201
  Updated By         | mike.gabriel at das-netzwerkteam.de
  Summary            | Saving of Kolab XML objects with non-7bit elements
                     | fails
  Queue              | Kolab
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


mike.gabriel at das-netzwerkteam.de (2015-12-29 09:02) wrote:

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