➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: email.Parser.Parser doesn't check for valid Content-Type
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: barry Nosy List: barry, jasonrm
Priority: normal Keywords:

Created on 2003-11-21 22:25 by jasonrm, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
traceback.txt jasonrm, 2003-11-21 22:26
1068873438.31426.msg jasonrm, 2003-11-21 22:27
Messages (3)
msg19075 - (view) Author: Jason R. Mastaler (jasonrm) Date: 2003-11-21 22:25 
See the attached traceback illustrating how to
reproduce the
problem.  A sample triggering message is also attached.

The problem is that the Content-Type is 'multipour
alternative', 
but the Content-Type field has a valid 'boundary='
parameter. 
The parser doesn't check that Content-Type is valid; it
just creates
sub-Message objects for each part it finds that is
separated by the 
boundary.  Then, when Generator goes to check
Content-Type, it
discovers that the content-type *is* invalid and it
returns 
'text/plain' instead! Generator tries to _handle_text
and instead
 finds the list of sub-Message objects.  BOOM!
msg19076 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2004-05-13 22:30 
Logged In: YES 
user_id=12800

This is going to be difficult to fix in email 2.5.  Can you
try the new parser in email3/Python 2.4cvs?  It doesn't fail
on this message.
msg19077 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2004-05-13 23:09 
Logged In: YES 
user_id=12800

Never mind that -- the fix is trivial.  I'll add this to
email 2.5.5 / Python 2.3.4.
History
Date User Action Args
2022-04-11 14:56:01adminsetgithub: 39582
2003-11-21 22:25:17jasonrmcreate