Encoding issues with CGI scripts wrapping otobo.psgi

[bschmalhofer]

Another class of failures from the cgi-bin wrapper scripts:

not ok 14 - Breadcrumb text 'Add Auto Response' is found on screen (is 'Automatische Antwort hinzuf�gen' should be 'Automatische Antwort hinzufügen')

Looks like funny double or triple encoding. Needs to be investigated.

Originally posted by @bschmalhofer in #1054 (comment)

[bschmalhofer]

Still confused. The PSGI spec says:

The response body MUST be returned from the application as either an array reference or a handle containing the response body as byte strings. The body MUST be encoded into appropriate encodings and MUST NOT contain wide characters (> 255).

But looking inside CGI::Handler::PSGI the content is a string with UTF-Flag on. This looks wrong. Calling utf8::encode($body) before printing the body apparently fixes the encoding issue. So, let's find out whether the body was decoded somewhere or was never encoded. If the body was never encoded, why is it working under Gazelle?

Just a reminder: Use Data::Peek::DDump($var) for showing the flags on a string,

[bschmalhofer]

The not encoded body might have been the sole problem. Let's run the test suite:

• under Docker, using Gazelle
• locally, using Apache 2.4 and Plack::Handler::PSGI
• locally, using Apache 2.4 and Modperl::Registry using the wrapper scripts in bin/cgi_bin

[bschmalhofer]

Running the test suite under Docker showed one error:

Failed test 'Article displayed using correct encoding'

at /opt/otobo/scripts/test/Selenium/Output/ArticleAttachmentHTMLViewer.t line 236.

Looks like you failed 1 test of 31.

Looks like double encoding of an article from the storage.

[bschmalhofer]

Removed the encoding to UTF-8 in Kernel::Output::HTML::Layout::Attachment(). Thus no double encoding and things look better now.

[bschmalhofer]

The remaining test failures do not seem to be related to the encoding. Closing this issue.

[bschmalhofer]

See also #1470.