mirror of
https://github.com/python/cpython.git
synced 2026-06-05 01:10:53 +00:00
7a4c6dfb88
RFC 2047 Section 6.2 requires that "any 'linear-white-space' that separates a pair of adjacent 'encoded-word's is ignored." The modern header value parser correctly implements that for unstructured headers, but had missed a case in structured headers. This could cause a parsed address header to include extraneous spaces in a display-name. Switch to @bitdancer's fix from review feedback. Recharacterize space between ews as fws after parsing in get_phrase. RDM: This fix is dependent on the fact that "subsequent" atoms will never have leading whitespace because that's been consumed already. I don't think it's worth adding extra code for the possibility of leading whitespace because the parser won't produce it. It's a bit of parser fragility in the face of code changes, but I think that's a minor concern given the parser design (which is that it consumes whitespace greedily) Co-authored-by: R David Murray <rdmurray@bitdance.com> |
||
|---|---|---|
| .. | ||
| mime | ||
| __init__.py | ||
| _encoded_words.py | ||
| _header_value_parser.py | ||
| _parseaddr.py | ||
| _policybase.py | ||
| architecture.rst | ||
| base64mime.py | ||
| charset.py | ||
| contentmanager.py | ||
| encoders.py | ||
| errors.py | ||
| feedparser.py | ||
| generator.py | ||
| header.py | ||
| headerregistry.py | ||
| iterators.py | ||
| message.py | ||
| parser.py | ||
| policy.py | ||
| quoprimime.py | ||
| utils.py | ||