Non-ASCII Attachment Name Not Properly Prepared in HTTP Header Content-Disposition

[Ian Li]

The current web client dose not encode the non-ASCII filename correctly in in HTTP Header Content-Disposition. For example, we have a attachment whose name is "优酷取回密码信息.eml", in current client-web, the server response of the file is:

HTTP/1.1 200 OK

Date: Thu, 17 Nov 2011 13:17:05 GMT

Content-Length: 2671

Content-Type: application/octet-stream

Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IuS8mOmFt+WPluWbnuWvhueggeS/oQ==?=
 =?utf-8?b?5oGvLmVtbCI=?=

Server: CherryPy/3.1.2

Set-Cookie: session_id=5a2f68a7724efb43a0fd6e5a28c3bc55aaaf1892; expires=Thu, 17 Nov 2011 14:17:05 GMT; Path=/

and the browsers ( Firefox and Chrome ) will not recognize the correct filename, instead, they will let you use "get" to save it.

We'd tested to add such an attachment in the 6.1 beta, the new web client handles the filename correctly and will prompt the user to save it with the right name ( sorry I don't have the dump of the HTTP traffic of this case now, but it has a form of "Content-Disposition: attachment; filename=FILENAME" , RFC 2183? ).

[Ian Li (ian.li)]

Well I think this is caused python unicode string is not properly encoded, here is the patch to fix it.