| Summary | Distorted looking Kolab XML mime data |
| Queue | Horde Framework Packages |
| Queue Version | Git master |
| Type | Bug |
| State | Duplicate |
| Priority | 1. Low |
| Owners | slusarz (at) horde (dot) org |
| Requester | thomas.jarosch (at) intra2net (dot) com |
| Created | 08/02/2013 (4353 days ago) |
| Due | |
| Updated | 08/08/2013 (4347 days ago) |
| Assigned | 08/06/2013 (4349 days ago) |
| Resolved | 08/06/2013 (4349 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | Yes |
State ⇒ Duplicate
commit c91ca76adf7239474e2a330847b23269a2baca84 necessary. Not sure
if broken, but at least changed behavior.
This was fixed by:
commit e895486b0d566d7e050e7a8959af19d0234d5d09
Author: Michael M Slusarz <slusarz@horde.org>
Date: Mon Aug 5 01:55:44 2013 -0600
Partially revert "[mms] Use the correct EOL string when transfer
encoding content (
Bug #12452)."This reverts commit e3bff89cc6549b895c8aefdff4204b4044309ae8.
This needs to be fixed by doing auto-EOL determination
Which makes this ticket a duplicate of
#12452.Assigned to Michael Slusarz
State ⇒ Feedback
commit c91ca76adf7239474e2a330847b23269a2baca84 necessary. Not sure if
broken, but at least changed behavior.
New Attachment: 0001-Fix-up-Kolab-XML-data-line-endings.patch
Patch ⇒ Yes
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Distorted looking Kolab XML mime data
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
with the recent line ending bugfix for Horde_Mime (#12452),
the Kolab XML data is rather unreadable.
Before the fix it looked like this:
----------------------------------
Content-Type: application/x-vnd.kolab.note; name=groupware.xml
Content-Disposition: inline; x-kolab-type=xml; filename=groupware.xml
Content-Transfer-Encoding: quoted-printable
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<note version=3D"1.0">
<uid>51fb73b0-ff4c-4c56-819d-09e1ac100191</uid>
<body>Mit EOL5<!--a75c305b1c0a6022--></body>
<categories></categories>
<creation-date>2013-08-02T08:54:08Z</creation-date>
<last-modification-date>2013-08-02T09:12:48Z</last-modification-date>
<sensitivity>public</sensitivity>
<product-id>Intranator Web Client-2.0.3 (api version: 1)</product-id>
<summary>Mit EOL5</summary>
<background-color>#000000</background-color>
<foreground-color>#ffff00</foreground-color>
</note>
----------------------------------
With the fix it looks like this:
----------------------------------
Content-Type: application/x-vnd.kolab.note; name=groupware.xml
Content-Disposition: inline; x-kolab-type=xml; filename=groupware.xml
Content-Transfer-Encoding: quoted-printable
<?xml version=3D"1.0" encoding=3D"UTF-8"?>=0A<note version=3D"1.0">=0A <ui=
d>51fb73b0-ff4c-4c56-819d-09e1ac100191</uid>=0A <body>Mit
EOL5<!--a75c305b1c0a6022--></body>=0A =
<categories></categories>=0A <creation-date>2013-08-02T08:54:08Z</creation=
-date>=0A <last-modification-date>2013-08-02T09:10:32Z</last-modification-=
date>=0A <sensitivity>public</sensitivity>=0A <product-id>Intranator Web =
Client-2.0.3 (api version: 1)</product-id>=0A <summary>Mit EOL5</summary>=
=0A <background-color>#000000</background-color>=0A <foreground-color>#ff=
ff00</foreground-color>=0A</note>=0A
----------------------------------
Horde_Kolab_Storage_Object::_appendMessage() calls Horde_Mime_Part->toString()
with 'canonical' set to true. Using a '\r\n' line ending is a good thing
for storing the message on an IMAP server.
I guess PHP's DOMDocument uses plain '\n' for the line ending
and this gets encoded by Horde_Mime to preserve it.
The most simple fix seems to convert the XML text line endings to '\r\n'
before passing it to Horde_Mime.
As a safety check, I would ensure there is no '\r\n' already in the
XML text output
before replacing the line endings. Line endings inside XML data
should be XML encoded anyway. Any drawbacks to anticipate?
Cheers,
Thomas