mirror of
https://github.com/python/cpython.git
synced 2025-08-22 17:55:18 +00:00
#21815: violate IMAP RFC to be compatible with, e.g., gmail
and others, including imaplib's own behavior. I'm applying this only to 3.6 because there's a potential backward compatibility concern: if there are servers that include ] characters in the 'text' portion of their imap responses, this code change could introduce a new bug. Patch by Lita Cho, reviewed by Jessica McKellar, Berker Peksag, Maciej Szulik, silentghost, and me (I fleshed out the comments with the additional info/concerns.)
This commit is contained in:
parent
01759d5554
commit
317f64f048
4 changed files with 73 additions and 1 deletions
|
@ -111,7 +111,15 @@ InternalDate = re.compile(br'.*INTERNALDATE "'
|
|||
# Literal is no longer used; kept for backward compatibility.
|
||||
Literal = re.compile(br'.*{(?P<size>\d+)}$', re.ASCII)
|
||||
MapCRLF = re.compile(br'\r\n|\r|\n')
|
||||
Response_code = re.compile(br'\[(?P<type>[A-Z-]+)( (?P<data>[^\]]*))?\]')
|
||||
# We no longer exclude the ']' character from the data portion of the response
|
||||
# code, even though it violates the RFC. Popular IMAP servers such as Gmail
|
||||
# allow flags with ']', and there are programs (including imaplib!) that can
|
||||
# produce them. The problem with this is if the 'text' portion of the response
|
||||
# includes a ']' we'll parse the response wrong (which is the point of the RFC
|
||||
# restriction). However, that seems less likely to be a problem in practice
|
||||
# than being unable to correctly parse flags that include ']' chars, which
|
||||
# was reported as a real-world problem in issue #21815.
|
||||
Response_code = re.compile(br'\[(?P<type>[A-Z-]+)( (?P<data>.*))?\]')
|
||||
Untagged_response = re.compile(br'\* (?P<type>[A-Z-]+)( (?P<data>.*))?')
|
||||
# Untagged_status is no longer used; kept for backward compatibility
|
||||
Untagged_status = re.compile(
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue