Re: [Imap-protocol] Gmail size fail

On Wednesday, 30 July 2014 15:20:06 CEST, Davide Gullo wrote:
> 29.07.14 17:07 >>> >>>>>>> send >>>>>>
> 29.07.14 17:07 >>> 5 UID FETCH 7848:7853 (UID X-GM-MSGID FLAGS RFC822.SIZE
> ENVELOPE BODY.PEEK[HEADER.FIELDS (References)] BODYSTRUCTURE RFC822)
> 29.07.14 17:07 >>> >>>>>>> end send >>>>>>
> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
> 29.07.14 17:07 <<< * 1 FETCH (X-GM-MSGID 1345148067064026772 UID 7848
> RFC822.SIZE 1372 BODY[HEADER.FIELDS (References)] {2}
> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
> 29.07.14 17:07 <<< <<<<<<< read <<<<<<

I don't see any problem in this log. Chances are that your client's IMAP 
parser does not properly support literals. Please note that the server says 
that the "BODY[HEADER.FIELDS (References)]" item which you are fetching 
contains exactly two bytes, the CR followed by LF. In C-syntax, that would 
be "\r\n".

So this is how the data sent by the server look like on the wire (again, 
using the C-style escaping of non-printable character):

BODY[HEADER.FIELDS (References)] {2}\r\n\r\n)\r\n

Let's break it down:

1) "BODY[HEADER.FIELDS (References)]" -- that's an identification what 
you're about to read.

2) SP (a space, " ") -- delimiter, as defined by the FETCH response format

3) "{2}\r\n" -- this means that a LITERAL follows. The overal size of the 
literal is two bytes. You *must* stop reading in a line-oriented manner 
right now, and switch to reading the exact number of bytes which the server 
tells you -- two bytes in this case.

4) "\r\n", i.e. CR LF -- actual header data. The header is missing, so the 
server sends just the CR LF which is the separator between the header and 
the body of a MIME message.

5) ")" -- consitutes the end of the FETCH response data

6) CR LF -- end of the line, end of the response

Let's see it in action:

> BODY[HEADER.FIELDS (References)] {2}
> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<

...at this point you know it's a literal. You should switch from 
read-until-end-of-line mode into reading-number-of-binary-bytes mode right 
now, and read two bytes in that mode.

> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<

Your code silently ignores CR LF line ends. You have a bug right here.

OK, you've read two bytes, you should switch to the standard mode of 
reading until EOL:

> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
> 29.07.14 17:07 <<< )
> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<

Right, end of response, everything is OK.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol