Each imap thread handles one connection. What comment 15 image shows is TB making the connection successfully and then server responds with BYE then the server closes the connection (sends FIN). The mozilla framework then ACKs the FIN but TB doesn't know about this. Then TB tries to send the CAPABILITY on the same now closed connection and the server responds with RST. The fact that TB doesn't know about a connection down in IMAP code until something is attempted to be sent was somewhat surprising to me when I learned about it some time back; but, it "simplifies" the IMAP handling since it becomes pretty much synchronous (code in thread sends imap command and waits for a response). Anyhow, I'll try to find a fix for the "unexpected" BYE response for the initial greeting. I'm think you are saying now that you have fixed the server so there is no initial BYE that TB is now working OK again? > I marked the LOG file expressly as binary so it arrives in its original form without changing line endings. I've never noticed a problem with line endings using my editors (vim or gvim). Looking with a binary "hexdump" program at logs I record here, I see the lines that are imap responses end with "0d0a" (as required by RFC) while the other lines end with just "0a" which is the standard linux/unix line ending. I'm not seeing "0d0d0a" in log files I produce here on linux. Anyhow, I'll set your log attachment back to binary and see what I see. : Ok, I see the 0d0d0a on imap lines but don't know why. File still looks OK in gvim.
Bug 1911950 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Each imap thread handles one connection. What comment 15 image shows is TB making the connection successfully and then server responds with BYE then the server closes the connection (sends FIN). The mozilla framework then ACKs the FIN but TB doesn't know about this. Then TB tries to send the CAPABILITY on the same now closed connection and the server responds with RST. The fact that TB doesn't know about a connection down in IMAP code until something is attempted to be sent was somewhat surprising to me when I learned about it some time back; but, it "simplifies" the IMAP handling since it becomes pretty much synchronous (code in thread sends imap command and waits for a response). Anyhow, I'll try to find a fix for the "unexpected" BYE response for the initial greeting. I'm think you are saying now that you have fixed the server so there is no initial BYE that TB is now working OK again? > I marked the LOG file expressly as binary so it arrives in its original form without changing line endings. I've never noticed a problem with line endings using my editors (vim or gvim). Looking with a binary "hexdump" program at logs I record here, I see the lines that are imap request or responses end with "0d0a" (as required by RFC) while the other lines end with just "0a" which is the standard linux/unix line ending. I'm not seeing "0d0d0a" in log files I produce here on linux. Anyhow, I'll set your log attachment back to binary and see what I see. : Ok, I see the 0d0d0a on imap lines but don't know why. File still looks OK in gvim.
Each imap thread handles one connection. What comment 15 image shows is TB making the connection successfully and then server responds with BYE then the server closes the connection (sends FIN). The mozilla framework then ACKs the FIN but TB doesn't know about this. Then TB tries to send the CAPABILITY on the same now closed connection and the server responds with RST. The fact that TB doesn't know about a connection down in IMAP code until something is attempted to be sent was somewhat surprising to me when I learned about it some time back; but, it "simplifies" the IMAP handling since it becomes pretty much synchronous (code in thread sends imap command and waits for a response). Anyhow, I'll try to find a fix for the "unexpected" BYE response for the initial greeting. I'm think you are saying now that you have fixed the server so there is no initial BYE that TB is now working OK again? > I marked the LOG file expressly as binary so it arrives in its original form without changing line endings. I've never noticed a problem with line endings using my editors (vim or gvim). Looking with a binary "hexdump" program at logs I record here, I see the lines that are imap request or responses end with "0d0a" (as required by RFC) while the other lines end with just "0a" which is the standard linux/unix line ending. I'm not seeing "0d0d0a" in log files I produce here on linux. Anyhow, I'll set your log attachment back to binary and see what I see. : Ok, I see the 0d0d0a on imap lines but don't know why. File still looks OK in gvim. Edit: P/S: Tried another editor that I seldom use (kate) and it shows a blank line after each line with the 0d0d0a.