[RCD] GB2312, ISO-2022-KR and other problems

[Vladimir Gorpenko]

First, I am not sure now that the problem with GB2312 was on a test
server before reload of system. Perhaps, it always worked correctly. In
any case, it has no errors log.

On the work server the error log present. As I understand, the record

[23-Sep-2016 10:48:49 Europe/Moscow] PHP Notice: No suitable function
found for UTF-8 encoding in
/var/www/html/mail/program/lib/Roundcube/rcube_charset.php on line 276

has a direct bearing on my problems with G2312. What does it mean?



Secondly, on this server in a log there is a group of the errors
relating to spell-checker.

[23-Sep-2016 10:24:05 Europe/Moscow] PHP Warning: fsockopen(): SSL
operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed in
/var/www/html/mail/program/lib/Roundcube/rcube_spellcheck_googie.php on
line 87
[23-Sep-2016 10:24:05 Europe/Moscow] PHP Warning: fsockopen(): Failed
to enable crypto in
/var/www/html/mail/program/lib/Roundcube/rcube_spellcheck_googie.php on
line 87
[23-Sep-2016 10:24:05 Europe/Moscow] PHP Warning: fsockopen(): unable
to connect to ssl://spell.roundcube.net:443 (Unknown error) in
/var/www/html/mail/program/lib/Roundcube/rcube_spellcheck_googie.php on
line 87

Thirdly, after the Linux updating RC ceased to work at the work server.
More precisely, the authentication page opens and works normally. The
wrong password is processed normally. But after input of the correct
password the RC page doesn't open, and the browser (Chrome) reports
ERR_EMPTY_RESPONSE. In the RC error log there is no diagnostics about
it.

I will be grateful for any consultations on search of the reasons of
this failure. Updating of Linux was very big.

One more question which doesn't have a direct relation on RC, but here
are specialists in e-mail. Perhaps, somebody will be so kind that he
will answer. In case of attachment of the file in the letter the title
in which cyrillic is encoded quite peculiar is created.

Content-Disposition: attachment;
filename*0*=UTF-8''%D0%9E%D1%82...

I can't find the function which is realizing such coding or descriptions
of the standard. I just don't know that I should look for.
How this coding is named?

[A.L.E.C]

Post by Vladimir Gorpenko
[23-Sep-2016 10:48:49 Europe/Moscow] PHP Notice: No suitable function
found for UTF-8 encoding in
/var/www/html/mail/program/lib/Roundcube/rcube_charset.php on line 276
has a direct bearing on my problems with G2312. What does it mean?

Either your PHP installation does not support this encoding or more
likely the text is not encoded properly so decoding failed.

Post by Vladimir Gorpenko
[23-Sep-2016 10:24:05 Europe/Moscow] PHP Warning: fsockopen(): SSL
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed in
/var/www/html/mail/program/lib/Roundcube/rcube_spellcheck_googie.php on
line 87
[23-Sep-2016 10:24:05 Europe/Moscow] PHP Warning: fsockopen(): Failed
to enable crypto in
/var/www/html/mail/program/lib/Roundcube/rcube_spellcheck_googie.php on
line 87
[23-Sep-2016 10:24:05 Europe/Moscow] PHP Warning: fsockopen(): unable
to connect to ssl://spell.roundcube.net:443 (Unknown error) in
/var/www/html/mail/program/lib/Roundcube/rcube_spellcheck_googie.php on
line 87

Error at spell.roundcube.net or something with its cert. You should
probably configure Roundcube to not use our service, but PHP
enchant/pspell modules.

Post by Vladimir Gorpenko
Thirdly, after the Linux updating RC ceased to work at the work server.
More precisely, the authentication page opens and works normally. The
wrong password is processed normally. But after input of the correct
password the RC page doesn't open, and the browser (Chrome) reports
ERR_EMPTY_RESPONSE. In the RC error log there is no diagnostics about it.

I don't know any errors in Roundcube or Apache log?

Post by Vladimir Gorpenko
Content-Disposition: attachment;
filename*0*=UTF-8''%D0%9E%D1%82...
I can't find the function which is realizing such coding or descriptions
of the standard. I just don't know that I should look for.

RFC 2231, we have some code to decode such headers in
rcube_imap::set_part_filename().

[Vladimir Gorpenko]

Post by A.L.E.C

Post by Vladimir Gorpenko
[23-Sep-2016 10:48:49 Europe/Moscow] PHP Notice: No suitable function
found for UTF-8 encoding in
/var/www/html/mail/program/lib/Roundcube/rcube_charset.php on line 276
has a direct bearing on my problems with G2312. What does it mean?

Either your PHP installation does not support this encoding or more
likely the text is not encoded properly so decoding failed.

Text is correct. The same letter is opened correctly in RC on my test
server. Both servers works with the same mail base and mail server.

By the way, whether can two RCube on different servers use the same SQL
base (Postgres)?

Post by A.L.E.C
Error at spell.roundcube.net or something with its cert. You should
probably configure Roundcube to not use our service, but PHP
enchant/pspell modules.

Ok

Post by A.L.E.C

Post by Vladimir Gorpenko
Thirdly, after the Linux updating RC ceased to work at the work server.
More precisely, the authentication page opens and works normally. The
wrong password is processed normally. But after input of the correct
password the RC page doesn't open, and the browser (Chrome) reports
ERR_EMPTY_RESPONSE. In the RC error log there is no diagnostics about it.

I don't know any errors in Roundcube or Apache log?

In RoundCube log.
In Apache error log there are many notices like this:
[notice] child pid 2315 exit signal Segmentation fault (11)
and nothing else.

On this server there is nothing except RC
These messages are absent on the server before update.
of the standard. I just don't know that I should look for.

Post by A.L.E.C
RFC 2231, we have some code to decode such headers in
rcube_imap::set_part_filename().

Thank you very much.

---
Best regards,
Vladimir Gorpenko

[A.L.E.C]

Post by Vladimir Gorpenko

Post by A.L.E.C
Either your PHP installation does not support this encoding or more
likely the text is not encoded properly so decoding failed.

Text is correct. The same letter is opened correctly in RC on my test
server. Both servers works with the same mail base and mail server.

Both have the same PHP and modules? You might also compare user
Preferences > Displaying Messages > Default Character Set (in Advanced
options section).

Post by Vladimir Gorpenko
By the way, whether can two RCube on different servers use the same SQL
base (Postgres)?

Sure you can, but on a working system it might be hard to switch. There
should be no problems if you start with empty database.

Post by Vladimir Gorpenko
In RoundCube log.
[notice] child pid 2315 exit signal Segmentation fault (11)
and nothing else.

That's it. In most such cases this is caused by some PHP bug. It's hard
to investigate these.

[Vladimir Gorpenko]

Post by A.L.E.C

Post by Vladimir Gorpenko

Post by A.L.E.C
Either your PHP installation does not support this encoding or more
likely the text is not encoded properly so decoding failed.

Text is correct. The same letter is opened correctly in RC on my test
server. Both servers works with the same mail base and mail server.

Both have the same PHP and modules?

No. I successfully updated a test server, but I can't update the working
server so far. Therefore versions of PHP differ (5.6.17 vs 5.6.25). I
compared yesterday outputs of phpinfo() from both servers. The
difference is insignificant, except numbers of versions, of course.

But on a test server more applications, than on the working server are
installed. For example, DRUPAL is set there.

Post by A.L.E.C
You might also compare user
Preferences > Displaying Messages > Default Character Set (in Advanced
options section).

UTF-8 in both cases.
On a test server several versions of RC, including 1.2.beta are set.
I tried to do test and working servers identical where it is possible,
but in many cases it was impossible. For example, the working server
works with chroot (Apache feature, not Linux chroot) whereas test server
- no.

Very much I want to hope that the problem with GB2312 will be fixed in
case of server updating, but I am not sure that it so.

Post by A.L.E.C
Sure you can, but on a working system it might be hard to switch. There
should be no problems if you start with empty database.

Thank you.

Post by A.L.E.C

Post by Vladimir Gorpenko
In RoundCube log.
[notice] child pid 2315 exit signal Segmentation fault (11)
and nothing else.

That's it. In most such cases this is caused by some PHP bug. It's hard
to investigate these.

Thanks, I understood. I learn to work with core dump.

Best regards,
Vladimir Gorpenko

[Vladimir Gorpenko]

Post by A.L.E.C

Post by Vladimir Gorpenko
By the way, whether can two RCube on different servers use the same SQL
base (Postgres)?

Sure you can, but on a working system it might be hard to switch. There
should be no problems if you start with empty database.

My servers are the virtual machines, I just clone them. Then, of course,
I change IP and a name. The original server and a clone use the same SQL
base, of course. Whether there is a danger in such approach?

Post by A.L.E.C

Post by Vladimir Gorpenko
In RoundCube log.
[notice] child pid 2315 exit signal Segmentation fault (11)
and nothing else.

That's it. In most such cases this is caused by some PHP bug. It's hard
to investigate these.

I went some other way. I put updates by parts. Eventually it was
clarified that operation of RC is broken in case of updating of group of
packages glibc*. I don't know what with it can be made farther. So far I
forbade updating of these packages. Then, maybe, I will invent
something.

All other packages was updated, including httpd and php*. The problem
with GB2312 remained. Probably, now it is necessary to deal with RC
diagnostics.

Best regards,
Vladimir Gorpenko