[issue28945] get_boundary invokes unquote twice

Eric Lafontaine added the comment: Hi, I would like to thank you for keeping up with me. I may not be easy at times, but please make me understand if it doesn't make sense :). Thanks bpoaugust and David, Eric Lafontaine -- ___ Python tracker

[issue28945] get_boundary invokes unquote twice

Eric Lafontaine added the comment: Hi, I would like to have a bigger set of user testing this patch before it gets approve... I really don't know all the extent to which it's a good/bad idea. The proposition was to not do the unquote in the rfc2231 collapse method. It doesn't break anythin

[issue28945] get_boundary invokes unquote twice

R. David Murray added the comment: The RFC compliance battle in email was lost long ago. We have to do our best to process what we get, and to produce only RFC correct output (unless retransmitting without change). That is Postel's law, and you can't successfully process Internet email witho

[issue28945] get_boundary invokes unquote twice

Eric Lafontaine added the comment: N.B., I've tried to do the keyword parameter on the get_param inside the get_boundary as well as I though it was a good Idea as well, but it was breaking some test cases (multiple ones). So I didn't pursue. N.B. I'm guessing (guessing) unquote must've been

[issue28945] get_boundary invokes unquote twice

Eric Lafontaine added the comment: Hi all, I hate this proposition. I feel it's a "victory" for the people who don't want to follow RFC standard and allow "triple"-quoting on things that aren't supposed to... Now that my opinion is said, I made 2 test case that should be added to the test_e

[issue28945] get_boundary invokes unquote twice

R. David Murray added the comment: I'm pretty sure you are correct in your guess that the utility is used by other code that depends on the <> unquoting. The new email policies (that is, the new header parsing code) probably do a better job of this, but get_param and friends haven't been wired

[issue28945] get_boundary invokes unquote twice

bpoaugust added the comment: According to RFC822, a quoted-string should only be wrapped in double-quotes. So I'm not sure why unquote treats <> as quotes. If it did not, then again this issue would not arise. However maybe utils.unquote is needed by other code that uses <>, so it cannot jus

[issue28945] get_boundary invokes unquote twice

bpoaugust added the comment: It looks like a simpler alternative is to just change boundary = self.get_param('boundary', missing) to boundary = self.get_param('boundary', missing, unquote=False) and let collapse_rfc2231_value do the unquoting -- ___

[issue28945] get_boundary invokes unquote twice

bpoaugust added the comment: I agree that strictly speaking the boundary is invalid. However: 'Be strict in what you generate, be liberal in what you accept' The mail package should never create such boundaries. However it should process them if possible. If the boundary definition is mangled by

[issue28945] get_boundary invokes unquote twice

Eric Lafontaine added the comment: Hi all, I believe this is the right behavior and what ever generated the boundary "<<>>" is the problem ; RFC 2046 page 22: _ The only mandatory global parameter for the "multipart" media type is the boundary parameter, which consists

[issue28945] get_boundary invokes unquote twice

New submission from bpoaugust: get_boundary calls get_param('boundary') which unquotes the value. It then calls utils.collapse_rfc2231_value which also calls unquote. This causes problems for boundaries that have two sets of quotes. For example, I have seen the following in the wild: Content-Ty