[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela added the comment: Thanks David and Barry! As much as it flatters my ego to be in the first place is MISC/ACK, I have to confess that my family name is "Cuenca Abela", Cuenca is not a middle name. Cheers, -- ___ Python tracker

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

R. David Murray added the comment: OK, patch (with comment tweaks to refer to this issue), and email minor version bump, applied to trunk in r78778. It turns out that bdecode was already deleted in email 5 in py3k. I did port the test in r78780. Thanks Joaquin Cuenca Abela, and you now have

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Barry A. Warsaw added the comment: Thanks for adding me to the nosy list. Yep, this code is pretty old so it doesn't surprise me that its implementation isn't quite right. Of course, I hate get_payload(decode=True) anyway and hope that goes away in email 6. Having said that, I don't think t

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela added the comment: Unfortunately the only way that I can see to reliably work around this is to bypass entirely get_payload, in this case fixing this bug will not affect people that do that negatively. Some people may have more control over their attachments and they are

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

R. David Murray added the comment: Your patch looks good, thank you. I just realized that Barry isn't nosy on this issue. I've checked, and the code in question dates back to email version 1.0...code of that long standing that exists specifically to implement the behavior we propose to chang

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela added the comment: I added a new subpart to msg_10.txt, that keeps the previous test and also tests the new behavior. Let me know if it's ok like this or if you still prefer to create a different msg file for testing this. Thanks, -- versions: +Python 2.5 Added f

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

R. David Murray added the comment: Thanks for working on this. For the most part your patch looks fine. Two comments: (1) it concerns me that by co-opting the existing test, we are no longer testing that decoding does not introduce a spurious newline :). (2) I think we should add a comment

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela added the comment: Hi, I've never before made a patch to Python, so take it with care. A couple of comments, I reused a test where all the attachments contained an ending newline, except for the base64 one (conveniently...) I think the comment in _bdecode that Andreas qu

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Changes by R. David Murray : -- versions: -Python 3.0 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

R. David Murray added the comment: Ah, I misunderstood, and did not see that the newline in question was inside the base64 string. Thank you for pointing out my mistake. Would either of you like to propose a patch, including a test case? (I've removed 2.5 because it is in security-fix-only m

[issue7143] get_payload(decode=True) eats last newline

Joaquin Cuenca Abela added the comment: Hi, RFC 2046, 5.1.1 refers to the CRLF that happens just before the boundary. It says nothing about an encoded CRLF. >From Andreas example, if you have: Content-Type: text/plain; name="test.txt" Content-Transfer-Encoding: base64 Content-Disposition: in

[issue7143] get_payload(decode=True) eats last newline

R. David Murray added the comment: The behavior you object to is in fact correct per RFC 2046, 5.5.1: The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part

[issue7143] get_payload(decode=True) eats last newline

Changes by Ehsan Amiri : -- nosy: +esam ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue7143] get_payload(decode=True) eats last newline

New submission from Andreas Thomas : The attachment of my sample email contains '123\n', but get_payload (decode=True) returns '123'. The source of this error is the function _bdecode from the email.utils module, which gets called for decoding base64 encoded payloads. Here the last \n gets stri