-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Description
Preconditions and environment
Magento version: 2.4.6-p6 AC
PHP 8.2.28
Maria DB: 10.6.19
This error appeared starting from the evening of October 1st CET (Italy).
Steps to reproduce
- configure DHL with production connection
- create an order with a special char (eg: è, é, ò, etc..) on product name or shipping address
- create the shipment shipping label during che shipment creation or in a shipped order without shipping label
Expected result
Shipping label is created and no error.
Actual result
Error given and the shipment can't be created (but the request on DHL arrives correctly):
[2025-10-01T16:32:47.374157+00:00] report.CRITICAL: Exception: Warning: SimpleXMLElement::__construct(): Entity: line 62: parser error : Input is not proper UTF-8, indicate encoding !"
"Bytes: 0xB0 0x50 0x20 0x41 in /[...]/vendor/magento/module-shipping/Model/Carrier/AbstractCarrier.php on line 673 in /[...]/vendor/magento/framework/App/ErrorHandler.php:62"
[stack]
Next Exception: String could not be parsed as XML in /[...]/vendor/magento/module-shipping/Model/Carrier/AbstractCarrier.php:673
Additional information
Notice:
The error occurs when there is a special character in the data being sent to DHL. The problem appears to be related to the conversion that occurs here: https://github.com/magento/magento2/blob/2.4.8/app/code/Magento/Dhl/Model/Carrier.php#L1763.
If the TEST environment is configured, the response returned by the API call retains the special characters, which are then converted and replaced with the "?" character. If the PRODUCTION environment is configured, however, the response already has the characters encoded, which are then further decoded.
This encoding on line 1763 appears to be useless and nonsensical, especially since the same call made on line 1926 (https://github.com/magento/magento2/blob/2.4.8/app/code/Magento/Dhl/Model/Carrier.php#L1926) does not include the conversion.
The code is the same on 2.4.6-p6: https://github.com/magento/magento2/blob/2.4.6-p6/app/code/Magento/Dhl/Model/Carrier.php
I've currently created a patch that simulates the error and understand whether or not to do the conversion:
Index: vendor/magento/module-dhl/Model/Carrier.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/vendor/magento/module-dhl/Model/Carrier.php b/vendor/magento/module-dhl/Model/Carrier.php
--- a/vendor/magento/module-dhl/Model/Carrier.php
+++ b/vendor/magento/module-dhl/Model/Carrier.php (date 1759480349776)
@@ -1767,7 +1767,14 @@
$request
)
);
- $responseBody = mb_convert_encoding($response->get()->getBody(), 'ISO-8859-1', 'UTF-8');
+ try {
+ $responseBody = mb_convert_encoding($response->get()->getBody(), 'ISO-8859-1', 'UTF-8');
+ $test = new \SimpleXMLElement($responseBody);
+ } catch (Exception) {
+ $responseBody = $response->get()->getBody();
+ } finally {
+ unset($test);
+ }
$debugData['result'] = $this->filterDebugData($responseBody);
$this->_setCachedQuotes($request, $responseBody);
} catch (Exception $e) {
Release note
No response
Triage and priority
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status