Opened 8 years ago
Closed 8 years ago
#1062 closed defect (worksforme)
ASCII-8BIT encoding when it should be UTF-8?
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | nginx-core | Version: | 1.10.x |
| Keywords: | Cc: | ||
| uname -a: | Linux li194-191 4.6.5-x86_64-linode71 #2 SMP Fri Jul 29 16:16:25 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.10.1
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) built with OpenSSL 1.0.2g-fips 1 Mar 2016 TLS SNI support enabled configure arguments: --prefix=/opt/nginx --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --with-cc-opt=-Wno-error --with-ld-opt= --add-module=/usr/local/rvm/gems/ruby-2.3.1/gems/passenger-5.0.30/src/nginx_module |
||
Description
Hello, big nginx fan here. But dismayed to find that it appears to be the culprit in crashing a Rails site, upon encountering extended characters in the database (ä, å, etc.).
Rails crashes out with ActionView::Template::Error (incompatible character encodings: UTF-8 and ASCII-8BIT) under nginx as a reverse proxy. This ONLY happens in production mode under nginx. I have tried with both Passenger and Puma behind the reverse proxy but it still happens. If I run Puma on it's own port and bypass nginx it works fine. And then I installed Apache and it works fine with Puma reverse-proxying to Apache.
All the setting of my database, app, etc. specifiy utf-8. The data in the database is utf-8. charset: utf-8 is in the nginx configs. The http headers claim utf-8. But somehow nginx (I guess?) is trying it as ASCII-8BIT.
It is not clear from your report if it's a bug in nginx. The following question on stackoverflow suggests it's not something nginx-related, but rather a coding or a template problem:
http://stackoverflow.com/questions/5286117/incompatible-character-encodings-ascii-8bit-and-utf-8
It's also unlikely to be an nginx bug as nginx doesn't try to change anything in client requests unless you've specifically configured it to do so (except a few protocol-related modifications which doesn't involve any encoding changes nor add anything 8-bit).
If you still think this is an nginx bug, please trace it down to something more specific (that is, what exactly causes the problem and what nginx can do differently to avoid it) and reopen the ticket.