Encoding::UndefinedConversionError #732
Comments
|
Looks like your platform has locale set to ascii, not utf-8, so default_external is trying to downconvert on write, but it's been a while so I'm partially guessing. |
|
In case that means nothing to you, try: export LANG=en_US.UTF-8Before launching your server. |
|
Setting UTF8 locale doesn't help me UTF8 request |
|
Ah i see, it's path info escaping issues. so this is actually an illegal URI per 2396. Setting the locale is changing things, but it's not valid utf-8, so setting to utf-8 doesn't actually change anything. We should probably open the log in binary mode and put data in it, but there are potential security implications to logging raw user binary to files. @jeremy was talking about this stuff the other day too, I forget which issue/PR it was on. In the meantime, you could fix this by providing a custom logger as the second parameter to the initializer, that logs in binary. e.g. logfile = open('log/binary.log', 'a+')
logfile.binmode
use Rack::CommonLogger, logfile
run App.new |
|
We had some similar issues on passenger rails, which lead us to submit the following issue Shouldn't the rack interface respect ruby's Encoding.default_external ? One of the author's of passenger says "The spec really should clarify this" and i'm sharing his opinion. |
|
No. As I said on the other issue, default_external does NOT specify anything about data over sockets. |
|
I've checked some rails default app servers. Puma and webrick encode them in UTF-8, thin and unicorn into ASCII-8BIT. LC_ALL setting has no effect on it, however people suggest to set this on several issue lists or posts. For those who stumblling upon it, just use Your are right, |
|
To be really really clear: LC_ALL should NOT affect any data coming from HTTP requests, period. |
|
Yes, the fragmented situation is bad. Here's where the bad comes from:
There may yet be a real problem in the things you describe, but this situation is subtle. If you can describe only what you observe, not what you "expect" that would help with diagnosis, as I can't easily determine in between expectations what's conjecture and what isn't. Unfortunately these issues are subtle and it's too easy for me to make a mistake if I'm not focusing clearly. To be clear here too: this does mean that I'm suggesting the logger should also not follow Encoding.default_external, as transcoding in a logger in this setting is bad. The logger in particular can only be fixed as I describe above. We don't really have a good choice alternative. Clients can send illegal data, and if you want a log of that you must accept to log it in it's raw binary form. Doing any transcoding would be a lie and prevent you from diagnosing root causes, should you mistakenly (and this is common) trust the logger. |
…L on Windows * #19187 * #19533 * macournoyer/thin#268 These are serious Rails 4 regression for Redmine Bitnami Windows users. https://community.bitnami.com/t/problems-with-3-0-1-installation-see-report-inside/30195/ It is not caused on webrick users. Related: * rack/rack#732 (comment) * phusion/passenger#1328
|
So it seems this issue is related to how Rack::CommonLogger's logger object (which is passed as an argument) handles encoded data. That doesn't seem to be a bug in Rack itself, and I don't think Rack::CommonLogger can fix the issue, because it can only assume the logger object supports I think Rack's SPEC's handling of encoding (treating input as binary, since you don't know the encoding) is fine and should not be changed. Basically, this issue can be fixed by the software using Rack::CommonLogger providing an argument that supports |
Found this errors in my error.log
option stdout_redirect
ENV: ruby 1.9.3-p484, puma-2.7.1
OS: Ubuntu 12.10 x86_64
The text was updated successfully, but these errors were encountered: