iconv problem in containers

[lazyfrosch]

Expected Behavior

Download should work.

Current Behavior

When downloading an Basket, it fails by showing HTML as text/plain in the browser, listing the exception:

iconv(): Wrong charset, conversion from `UTF-8' to `ISO-8859-11//IGNORE' is not allowed

This code causes it:

icingaweb2-module-director/application/controllers/BasketController.php

Lines 179 to 187 in 606d715

	$this->getResponse()->setHeader('Content-Disposition', sprintf(
	'attachment; filename=Director-Basket_%s_%s.json',
	str_replace([' ', '"'], ['_', '_'], iconv(
	'UTF-8',
	'ISO-8859-11//IGNORE',
	$basket->get('basket_name')
	)),
	substr($snapSum, 0, 7)
	));

I'm not sure why we are casting to ISO-8859-1 here, but it seems to fail on some platforms.

Steps to Reproduce (for bugs)

For now I use php on Alpine in lazyfrosch/icingaweb2

Your Environment

• Director version (System - About): 1.7.2
• Icinga Web 2 version and modules (System - About): 2.7.3
• Operating System and version: Alpine Linux 3.10
• Webserver, PHP versions: 7.3 with FPM under nginx

[Thomas-Gelf]

Seems to be an iconv issue in Alpine Linux. Similar issues:

• iconv(): Wrong charset, conversion from UTF-8' to ASCII//TRANSLIT//IGNORE' is not allowed  phpearth/docker-php#3
• iconv(): Wrong charset, conversion from UTF-8 to ASCII//TRANSLIT//IGNORE is not allowed nunomaduro/phpinsights#43

[lazyfrosch]

The magic of multiple implementations... Do we really need these cast?

[Thomas-Gelf]

ISO-8859-11 is a typo, this should read ISO-8859-1. But this shouldn't really matter and not be related to your issue. As far as I can remember, casting takes place as some browsers have issues with UTF-8. Problem is that RFC 2183 required only US-ASCII, and not all browsers understand encodings as of RFC5987. Please don't ask which versions might be affected, some googling shows that at least Safari used to be.

[Thomas-Gelf]

This is currently the only direct use of iconv, and it might be replaced with another piece of "ignore special characters"-code.

Currently there is at least one more use of iconv with //IGNORE in the pipeline. The communication with the Director Daemon Control Socket uses JSON-RPC. This will be an essential component for many upcoming features, as we'll delegate more and more caching/rendering-logic to the daemon. JSON is strict about UTF8, that's why unsafe messages travel through iconv('UTF-8', 'UTF-8//IGNORE', $message). The new JsonRpcLogWriter does so, as it might forward exceptions with unknown / third party or even partially binary messages.

So while replacing this single iconv() might help in the short run, I do not see not using iconv at all being a viable option.

[lazyfrosch]

Of course not the problem of Director, just want to make sure if we really need the iconv statement here.

[Thomas-Gelf]

@lazyfrosch: did you dig deeper into this issue? As far as I understood, this happens because of PHP binaries compiled in a "rough" way. Is that assumption true? Any idea of how to detect this issue via PHP application code? It doesn't feel good to know that there might be installations with half-broken iconv out there. Director should warn everybody running it in such an environment.

Additional input on this issue would be highly appreciated!

[lazyfrosch]

The problem seems to be that iconv in musl is not implemented to support that conversion, when using GNU iconv it works.

This change helps my problem:
lazyfrosch/docker-icingaweb2@353c5d0

I don't need any further investigation.