Bugs item #1102973, was opened at 2005-01-15 11:13
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102973&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Incorrect RFC 2231 decoding
Initial Comment:
The following message
---snip snip---
Content-Transfer-Encoding: base64
Content-Type: application/msword; x-mac-type=42494E41;
x-unix-mode=0644;
x-mac-creator=4D535744;
name="miriam's file.doc"
Content-Disposition: attachment;
filename*0="miriam's file"; filename*1=ths.doc
---snip snip---
Is incorrectly decoded according to RFC 2231. The bug
is in Utils.py in the decode_params() and
decode_rfc2231() functions. charset/lang encoding
should only be present on the first parameter, i.e.
filename*0 and even then, the quoted single quote
should not trip up the scanner. The problem is two fold:
- first, the unquoting of filename*0 happens in
decode_param(), too early for decode_rfc2231() to know
about it. Second, the logic in docode_rfc2231() is too
naive; it should take quoting into account to decide
whether a single quote is part of the file name or part
of the leading charset/lang encoding.
I've labeled this in the Group: Python 2.4, but it
really affects Python 2.3 as well, and the current head.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102973&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
