NotificationsYou must be signed in to change notification settings
Fork33.3k
Star69.8k

[3.13] gh-124452: Fix header mismatches when folding/unfolding with email message (GH-125919)#126917

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

bitdancer merged 1 commit intopython:3.13frommiss-islington:backport-ed81971-3.13

Nov 17, 2024

Merged

[3.13] gh-124452: Fix header mismatches when folding/unfolding with email message (GH-125919)#126917

bitdancer merged 1 commit intopython:3.13frommiss-islington:backport-ed81971-3.13

Nov 17, 2024

Conversation

Copy link

Contributor

miss-islington commentedNov 16, 2024•
edited by bedevere-appbot
Loading

The header-folder of the new email API has a long standing known buglet where
if the first token is longer than max_line_length, it puts that token on the next
line. It turns out there is also aparsing bug when parsing such a header:
the space prefixing that first, non-empty line gets preserved and tacked on to
the start of the header value, which is not the expected behavior per the RFCs.
The bug arises from the fact that the parser assumed that there would be at
least one token on the line with the header, which is going to be true for
probably every email producer other than the python email library with its
folding buglet. Clearly, though, this is a case that needs to be handled
correctly. The fix is simple: strip the blanks off the start of the whole
value, not just the first physical line of the value.

(cherry picked from commited81971)

Co-authored-by: RanKKIhliu86.me@gmail.com
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Bénédikt Tran10796600+picnixz@users.noreply.github.com

Issue:Parsing adds whitespace to the front of long headers #124452

pythongh-124452: Fix header mismatches when folding/unfolding with em…

2c543ec

…ail message (pythonGH-125919)The header-folder of the new email API has a long standing known buglet whereif the first token is longer than max_line_length, it puts that token on the nextline.  It turns out there is also a *parsing* bug when parsing such a header:the space prefixing that first, non-empty line gets preserved and tacked on tothe start of the header value, which is not the expected behavior per the RFCs.The bug arises from the fact that the parser assumed that there would be atleast one token on the line with the header, which is going to be true forprobably every email producer other than the python email library with itsfolding buglet.  Clearly, though, this is a case that needs to be handledcorrectly.  The fix is simple: strip the blanks off the start of the wholevalue, not just the first physical line of the value.(cherry picked from commited81971)Co-authored-by: RanKKI <hliu86.me@gmail.com>Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>