Closed
Bug 321924
Opened 20 years ago
Closed 20 years ago
Properly handle untagged "BAD" responses in IMAP protocol and clean up response handling
Categories
(MailNews Core :: Networking: IMAP, defect)
MailNews Core
Networking: IMAP
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: engel, Assigned: engel)
References
Details
Attachments
(1 file)
|
11.36 KB,
patch
|
Bienvenu
:
review+
|
Details | Diff | Splinter Review |
According to RFC3501, Sec. 7.1, an untagged BAD response "indicates a protocol-level error for which the associated command can not be determined; it can also indicate an internal server failure."
When such an untagged BAD response is received, |fCurrentCommandFailed = PR_TRUE| should be set, because in the current implementation only one command is sent at once.
(Bug 321599 motivated me to have a look into response handling; however, it turns out that concerning the issue reported there, the current implementation behaves correctly.)
|
Assignee | |
Comment 1•20 years ago
|
||
Add Parameter to |resp_cond_state()|, removing the field |fProcessingTaggedResponse|.
|
|
Assignee | |
Updated•20 years ago
|
Attachment #207207 -
Flags: review?(bienvenu)
|
|
Assignee | |
Updated•20 years ago
|
Status: NEW → ASSIGNED
|
|
||
Updated•20 years ago
|
Attachment #207207 -
Flags: review?(bienvenu) → review+
|
|
||
Comment 2•20 years ago
|
||
fixed on trunk, thx, Hans-Andreas!
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
|
||
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•