的X阿塞爾 - 重定向不python3和Django的1.5與非ASCII文件名

Question

工作，我想嘗試的Django和Python 3

我用：

• Nginx的
• uWSGI +蟒蛇從Ubuntu的回購3插件
• 蟒3.2
• 的virtualenv

當我把它的Python 2.7我有這個和它的工作：

... 
fname_ascii = fname.encode('utf-8') 
response = HttpResponse() 
response['X-Accel-Redirect'] = _convert_file_to_url(fname_ascii) 

現在與Python 3我換成1線：

response['X-Accel-Redirect'] = bytes(_convert_file_to_url(fname), 'utf-8') 

而這造成的：

Sat Apr 6 11:27:30 2013 - !!! uWSGI process 6296 got Segmentation Fault !!! 
Sat Apr 6 11:27:30 2013 - *** backtrace of 6296 *** 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(uwsgi_backtrace+0x25) [0x430a55] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(uwsgi_segfault+0x21) [0x430b31] 
Sat Apr 6 11:27:30 2013 - /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f2177f544a0] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyBytes_AsString+0) [0x7f217417e280] 
Sat Apr 6 11:27:30 2013 - /usr/lib/uwsgi/plugins/python32_plugin.so(py_uwsgi_spit+0x45f) [0x7f217455c5ef] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyEval_EvalFrameEx+0x6230) [0x7f217405f310] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyEval_EvalCodeEx+0x687) [0x7f21741289e7] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(+0x12acff) [0x7f2174128cff] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyObject_Call+0x7a) [0x7f217413f8aa] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(+0xac98d) [0x7f21740aa98d] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyObject_Call+0x7a) [0x7f217413f8aa] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(+0xc773c) [0x7f21740c573c] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyObject_Call+0x7a) [0x7f217413f8aa] 
Sat Apr 6 11:27:30 2013 - /usr/lib/libpython3.2mu.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7f2174180cb7] 
Sat Apr 6 11:27:30 2013 - /usr/lib/uwsgi/plugins/python32_plugin.so(python_call+0x24) [0x7f21745592f4] 
Sat Apr 6 11:27:30 2013 - /usr/lib/uwsgi/plugins/python32_plugin.so(uwsgi_request_wsgi+0x119) [0x7f217455b6c9] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(wsgi_req_recv+0x7f) [0x40dd5f] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(simple_loop+0x112) [0x42be12] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(uwsgi_ignition+0x18a) [0x430faa] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(uwsgi_start+0x2c36) [0x434586] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi(main+0xed4) [0x40d6e4] 
Sat Apr 6 11:27:30 2013 - /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f2177f3f76d] 
Sat Apr 6 11:27:30 2013 - /usr/bin/uwsgi() [0x40d781] 
Sat Apr 6 11:27:30 2013 - *** end of backtrace *** 
Sat Apr 6 11:27:30 2013 - DAMN ! worker 2 (pid: 6296) died :(trying respawn ... 
Sat Apr 6 11:27:30 2013 - Respawned uWSGI worker 2 (new pid: 6299) 

我也試過了：

response['X-Accel-Redirect'] = _convert_file_to_url(fname) 

，但得到：

BadHeaderError at /my_url 

Header values can't contain newlines (got '=?utf-8?b?...=?=\n =?utf-8....=?=\n =?utf-8?b?...=?=') 

uWSGI設置更改：

[uwsgi] 
... 
plugins = python32 
virtualenv = /pyenvs/p3_general/ 

如果有人有這個問題 - 寫你知道什麼。
或者它可能只是一個錯誤。但它似乎是一個uwsgi插件的bug。

更新1：

我使用PIP安裝uwsgi 1.9.5：

Starting uWSGI 1.9.5 (64bit) on [Sat Apr 6 16:27:03 2013] 
... 
Python version: 3.2.3 (default, Oct 19 2012, 19:55:38) [GCC 4.7.2] 

同樣的問題。

我忘了提 - 這僅適用於帶有非ASCII符號（俄語在我的情況）的文件名

更新2發生：

使用urllib.parse.quote uWSGI工作，但Nginx的給出錯誤：

• failed (36: File name too long)（容易地固定）
• open() "/data/SORT/%D1%84%D1%8B%D0%B2%D0%B0%20%D1%84%D1%8B.ogg" failed (2: No such file or directory)

所以我覺得這個問題是 - uWSGI +蟒蛇3

Answer 1

我強烈建議你使用uWSGI穩定版本（1.4或1.9的樹）。該debian提供的版本是非常陳舊，並與各種已知的錯誤