It would appear that there are special, non-printing chars in data you provided.

I copy/pasted the data into my editor, and it showed a 'DC3' char before the 'Æ' symbol, and an 'SOH' after the 'ø
'. If I save the file and dump it's contents as hex, here's what happens

$ hexdump -C /tmp/foo

00000000  4e 4f 54 49 43 45 20 30  36 37 34 20 54 48 52 44  |NOTICE 0674 THRD|

00000010  3a 20 78 13 c3 86 c2 b7  78 13 c3 86 c2 b7 0a 4e  |: x.....x......N|

00000020  4f 54 49 43 45 20 30 36  37 34 20 54 48 52 44 3a  |OTICE 0674 THRD:|

00000030  20 c3 b8 01 40 c2 af c3  b8 01 40 0a              | ...@.....@.|

0000003c

Note the 'DC3' maps to 0x13 and 'SOH' to 0x01.

1.3 chokes on these due to strict html checking, and I guess these control chars are considered invalid in the DTD.

I'm not really sure how to fix this at the moment; in the meanwhile as a workaround, I suggest you manually edit the bugnote to remove the control chars.

As a temporary workaround I suggest to change http_api.php line 135
from
header( 'Content-Type: application/xhtml+xml; charset=UTF-8' );
to
header( 'Content-Type: text/html; charset=UTF-8' );

and html_api.php line 321
from
echo "\t", '<meta http-equiv="Content-type" content="application/xhtml+xml; charset=UTF-8" />', "\n";
to
echo "\t", '<meta http-equiv="Content-type" content="text/html; charset=UTF-8" />', "\n";

@atrol - not sure dhx would like your workaround ;)

To get to the bottom of this issue:

• user's data contains control characters
• valid "data" characters (i.e. displayable text in this case) as per current version of XML 1.0 specification [1] exclude all control characters except tab, cr and lf

Therefore, I believe that the proper fix would be revise string_html_specialchars() to exclude invalid characters from the display string.

Suggested change https://github.com/dregad/mantisbt/commit/fix-14744

Thoughts ?

[1] http://www.w3.org/TR/2008/REC-xml-20081126/#NT-Char

EDIT dregad: see separate issue 0014748 for follow up on the note below.

There is another error happening when having a attachment of jpg image. When generating summary report in HTML, it breaks on line 194, col 194:

<td class="print" colspan="5">
    Error#504.jpg (116,726) <span class="italic">2012-09-25 16:33</span><br />http://10.96.99.119/mantisbt/file_download.php?file_id=1&type=bug<br /><img src="file_download.php?file_id=1&type=bug" alt="jpg" /><br />

It outputs fine after I changed the '&' before "type=bug" alt="jpg" />
" to '&'.

phyllisl, your note 0014744:0032953 has nothing to do with the problem at hand. Can you kindly

1. open a separate issues for each individual problem, and
2. trim your screenshots attachments, to avoid unnecessary clutter

Furthermore, your last screenshot is even useless as it does not even show the character where the error occurs. When you have text output, it is generally better to copy-paste the text rather than an image, and include it (within html 'pre' tags if necessary) in your bug report or note.

Thanks for your understanding

In addition, your feedback on 0014744:0032950 would be appreciated - does that fix your problem ?

@atrol - not sure dhx would like your workaround ;)
Probably he will not like it.
That's why I wrote TEMPORARY WORKAROUND and not something like FIX ;)

Maybe we should TEMPORARY add something like $g_enable_browser_xhtml_validation = ON/OFF

[Edited]
Forget $g_enable_browser_xhtml_validation = ON/OFF
Users will set it to OFF and we will get no longer any reports for issues caused by the validation.

0014744:0032950

This does fix the problem of special characters and the summary page is generated.

Thank you!

Thanks for your feedback.

I removed the attachment related to note 0014744:0032953 and added it to 0014748

Just found out that if you have special characters in the name of an custom field, or in the name of a project, the summary report would not generate properly because of the special characters.

Apparently, there needs string_html_specialchars() at two other spots in summary_api.php at around line 57 and 394

Follow up on 0014744:0033110 in new issue 0014811

I've applied the same fix to the SOAP API on the master-1.2.x branch to make sure it outputs correct XML and it does. But on the other hand it strips out (some?) non-Latin-1 characters, for instance you will not see anything written in Russian.

I've added a failing test to the SOAP API with https://github.com/mantisbt/mantisbt/commit/88a332a6c980ecf827ac654798e8b5317cf233ab . The same strings fail to be displayed on an installation from master so I also reopen this issue.

I'm not sure if the characters are valid for UTF-8 or not, but I'm sure we need to find a solution for outputting them.

See 0014157 for a proposed revised regex which (as far as I can tell) does not filter out Russian chars, and hopefully also works for the rest of it ;-)

Feedback appreciated.

Added commit with new regex based on rombert's feedback in 0014157.

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch