[dovecot] FETCH BODY[part]<partial>
2003-03-24 12:59 Timo Sirainen tss@iki.fi
This CVS update didn't actually seem to fix the problem. I still get the problem as before, like this capture:
10 UID FETCH 60 BODY.PEEK[]<8192.1915>
- 60 FETCH (UID 60 BODY[]<8192> {1915}
) 10 OK Fetch completed.
Not quite 1,915 bytes =). Perhaps the "[]" (without a part) is confusing it? But still, it grabs the first chunk correctly. At any rate, any input would be great.
On Tue, 2003-03-25 at 21:53, Jesse Peterson wrote:
This CVS update didn't actually seem to fix the problem. I still get the problem as before, like this capture:
10 UID FETCH 60 BODY.PEEK[]<8192.1915>
- 60 FETCH (UID 60 BODY[]<8192> {1915}
) 10 OK Fetch completed.
Does this happen every time now? What if you run the "imap" binary directly and ask this? What if you skip the first block and ask only the second? Is the message really 10107 bytes long?
Not quite 1,915 bytes =). Perhaps the "[]" (without a part) is confusing it? But still, it grabs the first chunk correctly. At any rate, any input would be great.
I can't get this to break with me..
Timo Sirainen wrote:
On Tue, 2003-03-25 at 21:53, Jesse Peterson wrote:
This CVS update didn't actually seem to fix the problem. I still get the problem as before, like this capture:
10 UID FETCH 60 BODY.PEEK[]<8192.1915>
- 60 FETCH (UID 60 BODY[]<8192> {1915}
) 10 OK Fetch completed.
Does this happen every time now? What if you run the "imap" binary directly and ask this? What if you skip the first block and ask only the second? Is the message really 10107 bytes long?
I'll give all these a try and let you know.
Not quite 1,915 bytes =). Perhaps the "[]" (without a part) is confusing it? But still, it grabs the first chunk correctly. At any rate, any input would be great.
I can't get this to break with me..
Could it possibly be that my indexes (from before the update) were screwed and deleteing them would help? Maybe it cached the body or summin, I'll do it anyways to be sure.
I've found a couple of things:
When the reply to the fetch is given, it seems to be missing a ")" on the end:
23 UID FETCH 48 BODY.PEEK[]<8192.1915>
- 48 FETCH (UID 48 BODY[]<8192> {1915}
How does an IMAP client learn the size of a message? Because the size of this particular message is 10107 bytes (header + message, in a maildir file). The IMAP client (Mac OS X Mail.app) asks for two chunks of the body: 8192 and 1915. Together these two make 10107, but that's 1448 bytes too big. In fact, 1448 is the size of the header it requests:
21 UID FETCH 48 BODY.PEEK[HEADER]
- 48 FETCH (UID 48 BODY[HEADER] {1448}
Together, that is 11555, too much.
Further investigation gives me this:
For another message that is 11821 bytes (header+body,maildir), this is the request:
37 UID FETCH 20:* (INTERNALDATE UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (date subject from to list-id)])
- 17 FETCH (UID 20 FLAGS (\Recent) INTERNALDATE "26-Mar-2003 09:47:03
-0800" RFC822.SIZE 12116 BODY[HEADER.FIELDS (DATE SUBJECT FROM TO LIST-ID)] {148}
If you multiply the simple header returned by this (148) by two, then add that to the filesize of the message, you get 12117 (minus a CR probably). Is this how RFC822.SIZE is defined?
Anyway, in conclusion, it now DOES work, it's just that apparently Mail.app cached the old file sizes on the broken messages, so those didn't work (i think).
Thanks again Timo.
On Wed, 2003-03-26 at 19:59, Jesse Peterson wrote:
When the reply to the fetch is given, it seems to be missing a ")" on the end:
It's sent after the message text.
23 UID FETCH 48 BODY.PEEK[]<8192.1915>
- 48 FETCH (UID 48 BODY[]<8192> {1915}
How does an IMAP client learn the size of a message? Because the size of this particular message is 10107 bytes (header + message, in a maildir file).
IMAP requires that linebreaks are CR+LF. In maildir files you have only LFs. So there's one extra byte per each line.
If you multiply the simple header returned by this (148) by two, then add that to the filesize of the message, you get 12117 (minus a CR probably). Is this how RFC822.SIZE is defined?
RFC822.SIZE is just the full size of message, again with CR+LFs.
Anyway, in conclusion, it now DOES work, it's just that apparently Mail.app cached the old file sizes on the broken messages, so those didn't work (i think).
OK, good. Now only thing left to fix is SSL proxy.
IMAP requires that linebreaks are CR+LF. In maildir files you have only LFs. So there's one extra byte per each line. RFC822.SIZE is just the full size of message, again with CR+LFs.
D'0h, I feel like an idiot now. =)
OK, good. Now only thing left to fix is SSL proxy.
What happens to be wrong with the SSL proxy?
On Thu, 2003-03-27 at 01:42, Jesse Peterson wrote:
OK, good. Now only thing left to fix is SSL proxy.
What happens to be wrong with the SSL proxy?
It seems to get stuck sometimes. I think it's now fixed in CVS. Or this is with openssl at least, I'm not really sure how well gnutls works.
participants (2)
-
Jesse Peterson
-
Timo Sirainen