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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Header.decode_header eats up spaces #43184
Comments
The Header.decode_header function eats up spaces in See the following source: This prints: This should print: This appears in Python 2.3 but the source code of the This patch (not extensively tested though) seems to --- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.000000000 +0200
+++ Header.py 2006-04-10 12:27:27.000000000 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
- unenc = parts.pop(0).strip()
+ unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None: |
Logged In: YES I can confirm this bug and have been bitten by it as well. |
Hello, |
I propose the attached patch. RFC 2047 specifies to ignore whitespace between encoded-words, but IMHO not between ordinary text and encoded-words. |
IIRC, I tried the OP's patch and it broke too many of the email package's test suite. I made an attempt at fixing the problem to be much more RFC compliant, but couldn't get the test suite to pass completely. This points to a much deeper problem with email package header management. I don't think the problem is a bug, I think it's a design flaw. |
Would someone like to comment on Georg's patch. |
Georg's patch no longer applies to py3k. I ported it, but the result is not functional. It causes extra spaces during header generation, because it is there that email4/5 "deals" with "ignoring" spaces between encoded words by *adding* spaces when they are adjacent to non-encoded words. (In general email4/5 compresses runs of whitespace into single spaces.) I tried fixing that, but then ran in to the fact that header parsing/generation currently depends on the whitespace compression in order to handle the header folding cases. So, the logic used for header parsing and generation in emai5 does not allow for an easy patch to fix this bug. I'm deferring it to email6, where I an rewriting the header parser/generator. |
I've been bitten by this too (in python up to 2.7 in roundup the bug-tracker). We're currently using a workaround that re-inserts spaces, see git on roundup.sourceforge.net file mailgw.py method _decode_header_to_utf8 RFC2047 even has a test-case at the end, it specifies: encoded form displayed as note the space between 'a' and 'b' above. Spaces between non-encoded and encoded parts should be preserved. And it's probably a good idea to put the examples from the RFC into the regression test. |
Antoine, I marked this for Python 3.3 only because there is no good way to fix it in 2.7/3.2. (If someone comes up with a way I'll be happy to review it, though!) |
This is fixed by the fix in bpo-1079. Ralf found a *relatively* backward compatible way to fix it, but since the point is preserving whitespace that wasn't preserved before, there is an unavoidable behavior change, so it can't be backported. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: