New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UnicodeEncodeError in middleware.py #1601
Comments
Do you know which characters are being rendered and in which panels they are coming from? |
I made some progress and eventually managed to find the surrogates that are mentioned in the stack trace: In one of my apps, I have static files with german umlaut characters, e.g. These files are listed in the "Static files" panel in section My current work-around is to replace only the surrogate characters: rendered = rendered.replace('\udcc3\udcbc', '___???___')
rendered = rendered.replace('\udcc3\udca4', '___???___')
bits[-2] += rendered However, I still have no idea how the surrogate characters come up in the first place: My system is Ubuntu 20.04 LTS and there is nothing special about the above mentioned files at all. Can anyone reproduce this? |
Is it possible that your filesystem encoding (in Python) isn't set to UTF-8? My systemd user units always contain the following environment variables: I remember that we had many problems in the past without this; the server process would basically crash each time someone uploaded files containing umlauts. I'm not 100% sure if this happened only with Python 2 or also with Python 3 though so this could be a dead end. |
... that being said, maybe the toolbar should expect filenames which cannot be properly converted to UTF-8... |
@matthiask thanks for your hints! You're right, my filesystem encoding in Python was indeed set to ascii and I could resolve the problem by setting Although the problem was eventually caused by my Apache config alone, this seems to be a very complicated topic. Maybe it would be possible for djdt to warn about non-UTF-8 filesystem encodings? (Or better about filenames that cannot be properly decoded?) Thank you! |
Oh yeah, it's complicated and very annoying. I'm unsure what we should do. On one hand django-debug-toolbar shouldn't crash, on the other hand it's documented that Django expects an UTF-8 environment (not C) here https://docs.djangoproject.com/en/4.0/ref/unicode/#files So maybe the somewhat strange behavior is to be expected? I didn't even know that this was documented, this section has been added recently (in 2015 😅) |
Thanks for the link! My project started in 2011 and even though I regularly work through all Release Notes very carefully, it is easy to miss such updates in the docs, useful and worthwhile as they are. Imho, it would be ideal if this could be covered with a Django system check, which however is in vain here, given that command line shells and webservers tend to have different environments. |
We already discussed adding checks for issues which are (arguably) only surfaced but not really caused by django-debug-toolbar in the past; the last time it was about static files as well #1318 Such things are really hard to debug sometimes if you don't already know where to look so I think it may be time to revisit my stance on this. I wrote that I am slightly against adding checks for other apps (even if those other apps are bundled with Django) but I'm not so sure anymore. Here would probably be the place for such a new check: django-debug-toolbar/debug_toolbar/panels/staticfiles.py Lines 182 to 203 in 54e63f0
|
This is looking great! :-) If I understand things correctly though, it might be possible that an error that raises an exception (such as here with the surrogates) dominates the checks, as it never gives them a chance to be displayed as part of the normal output. |
Oh, and this would be a check for the Django core, not for a Django app, not even a built-in. |
Since we haven't seen any thank yous or emojis in this thread, I'm closing this issue rather than implementing a check. |
Hello,
using Django Debug Toolbar 3.2.4 with Django 4.0.3, I get the following stack trace:
The related section around line 93 in
debug_toolbar/middleware.py
is:If I replace line
with
in order to get rid of any problematic characters, it works.
Unfortunately, I've no idea what might cause this and I'm not sure how to proceed from here?
The text was updated successfully, but these errors were encountered: