Thanks a lot for your responses. I managed to track down the problem
further with the help of the information you provided.
In my wsgi script I have:
sys.stdout = sys.stderr
(So that's the reason why output is redirected to error files as
Graham mentioned.)
My view file is:
# coding=utf-8
...
def home(request):
print u"İşÖ"
Both of the machines have default encoding of 'ascii'. Linux box have
mod_wsgi 2.3 installed.
1- When running on the Mac OS X box as development sever (./manage.py
runserver) the view prints "İşÖ" as expected
2- When running on the Linux box as development sever (./manage.py
runserver) the view prints "İşÖ" as expected, too
3- When running on the Linux box on apache+mod_wsgi, the print
statement raises
"UnicodeEncodeError: 'ascii' codec can't encode character u'\u0130' in
position 0: ordinal not in range(128)"
This leads me to the conclusion that it's related to mod_wsgi and one
should not try to 'print' unicode strings within it.
Although I can't understand the exact reason event after your
explanations, I wanted to mention my findings, for future reference
for anyone who comes across the same problem.
Regards,
Polat Tuzla
On Feb 17, 12:48 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> On Feb 17, 3:01 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
>
> > > I think I should have clarified some more facts about my setup.
> > > 1- On mac, django is running on dev mode, so stdout is the console. On
> > > linux, it'smod_wsgi, so stdout is redirected to apache error log
> > > files, on which I'm issuing a "tail -f" thorough ssh.
>
> > I was a little surprised that stdout was redirected to the error logs in
> > mod_wsgi, but it seems that that is indeed the case.
>
> In default configuration mod_wsgi does not send stdout to the Apache
> error logs. In fact if you try and output to stdout mod_wsgi will
> complain and raise an exception. This is because mod_wsgi deliberately
> restricts writing to stdout to discourage people using 'print' for
> debug. This is done because by doing so you make your WSGI application
> less portable. In particular, your WSGI application would break in a
> WSGI hosting mechanism which uses stdout to communicate the response
> back to the web server. Such a mechanism is used for CGI-WSGI bridges.
>
> Thus, if stdout is going to the Apache error logs it is because the
> user made a conscious decision to redirect it there by disabling the
> mod_wsgi restriction on using stdout. This can be done by using
> WSGIRestrictStdout directive, or explicitly reassigning sys.stdout to
> be sys.stderr.
>
> All this stuff about stdout is described in:
>
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Writing_To_St...
> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
>
> > I don't know what
> > mod_wsgi might be doing to character encoding on output (maybe nothing,
> > but maybe that's playing a role).
>
> Uses:
>
> PyArg_ParseTuple(args, "s#:write", &msg, &len)
>
> so presumably the default encoding. If the default encoding isn't
> UTF-8, then you may have problems in trying to outputUnicodestrings
> if it cannot be represented in whatever default encoding is. This
> would likely result in exception and so perhaps what you are seeing.
>
> > However, instead of using print, I
> > would recommend using Python's logging module and sending the results to
> > a dedicated logging file.
>
> > Apache error logs aren't a great place for audit-style logging, since
> > there's so much other (Apache-specific) stuff in there.
>
> If the integrity of the information being logged is important, then I
> also would be recommending logging to your own files.
>
> The mapping of sys.stderr to Apache error logging mechanism should be
> seen as more of a failsafe default for minor logging. If you need a
> more serious logging system, implement your own.
>
> Mapping to Apache error logging mechanism has a couple of
> shortcomings, plus a bug in mod_wsgi 2.3. The bug stems from fact that
> it is trying to force data into a C API call that takes NULL
> terminated C strings. Forgot about that aspect of it so it is
> currently truncating at any embedded null in something which is
> logged. So, okay if text, but shove binary data down it and it will
> not be happy. This is addressed in mod_wsgi 3.0. All it can do though
> is interpret an embedded null as if it was a newline because Apache
> logging API doesn't understand concept of length.
>
> The reason that Apache logging API is used rather than just stuffing
> it direct into file descriptor for log file, is that it allows Apache
> to use syslog for logging or for it to be intercepted by any other
> custom Apache modules that want to process error log messages. Also
> Apache adds useful date/time information to each line. A limitation of
> the logging API though is that also has a maximum line length. Thus,
> it also throws away anything over about 8192 bytes when have a really
> long line. I am looking at how can easily work around this limitation
> for mod_wsgi 3.0. Likely will just treat it as if newline had been
> inserted. The problem though is knowing at what point to artificually
> insert the newline, as where Apache will truncate it varies based on
> all the prefix information it adds.
>
> Note that the above limitations also apply to wsgi.errors passed in
> WSGI request environment. Anything output to wsgi.errors also ends up
> in Apache error log, but also has client and referrer information
> prefix as well as date/time. It is this referrer information that
> makes it hard to work out to artificially truncate a line.
>
> If the limitations on what successfully gets through with stderr are a
> problem, then one thing you can do is restore the original Python
> stderr object.
>
> sys.stderr = sys.__stderr__
>
> This will result in it going direct to the main Apache error log. You
> do need to ensure you explicitly flush the data in stream though to
> have it appear.
>
> Note that whereas sys.stderr for mod_wsgi daemon process defined in
> VirtualHost context goes to VirtualHost specific error log file,
> anything sent to sys.__stderr__ will still got to main Apache error
> log file. This is addressed in mod_wsgi 3.0, with it going to correct
> VirtualHost specific log file.
>
> Anyway, this is probably a lot more detail than what you what you want
> to know and which is appropriate for this list. For this sort of
> question a it pertains to mod_wsgi you perhaps would have been better
> going to the mod_wsgi list.
>
> Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
