Last modified: 2014-09-23 23:16:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T31282, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29282 - Some broken mailers (M$ Exchange) corrupt quoted-printable headers
Some broken mailers (M$ Exchange) corrupt quoted-printable headers
Status: NEW
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-06 14:39 UTC by Vitaliy Filippov
Modified: 2014-09-23 23:16 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch for UserMailer (2.10 KB, patch)
2011-06-06 14:39 UTC, Vitaliy Filippov
Details

Description Vitaliy Filippov 2011-06-06 14:39:15 UTC
Created attachment 8624 [details]
Patch for UserMailer

Some broken mailers (f**king M$ Exchange) corrupt quoted-printable headers that are longer than 255 characters. We solved it simply by changing Quoted-Printable encoding to MIME-Base64 (patch is attached, just for notice). Or are there also problems with Base64? Why do you use Quoted-Printable?
Comment 1 Sam Reed (reedy) 2011-06-06 15:39:18 UTC
The patch doesn't follow our coding guidelines
Comment 2 Brion Vibber 2011-06-06 18:04:32 UTC
Well, base64 is obviously a lot less legible for the case of latin text. :)

Quoted-printable is also easier to debug even for non-Latin text as the individual bytes can be seen, whereas base64 squishes a bitstream together.

I have no idea whether base64 is actually more compatible or not than quoted-printable.

This patch also adds two code paths and output formats: one path taken when iconv_mime_encode() is available -- where long output will be split over lines -- and one when it's not, where long output is not split.

Are there any compatibility issues with long unwrapped lines of base64 stuff? Any differences in behavior to be expected between the two?
Comment 3 Vitaliy Filippov 2011-06-06 20:13:08 UTC
:) agreed :)

(In reply to comment #1)
> The patch doesn't follow our coding guidelines
Surely yes ( for example it's hard to add ( spaces after braces ) everywhere when everything other that you work on does not have them ), but it's attached just for information. :)

> This patch also adds two code paths and output formats
Agree, it's not good. I can't tell about the difference by now, need to check.
Comment 4 Vitaliy Filippov 2011-06-06 20:13:45 UTC
Btw, is there some automatic tool to check your code formatting style?
Comment 5 Sam Reed (reedy) 2011-06-07 13:49:26 UTC
(In reply to comment #4)
> Btw, is there some automatic tool to check your code formatting style?

http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/code-utils/stylize.php
Comment 6 Sumana Harihareswara 2011-11-08 13:11:46 UTC
It looks like this patch has received some review, so I am adding the "reviewed" keyword.  Vitaliy, do you have time to update it, and interest in doing so?  Thanks.

https://www.mediawiki.org/wiki/Coding_conventions has had some updates since June, so linking for reference.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links