On Thu, 23 Oct 2008 19:06:19 +0300, Timo Sirainen <tss@iki.fi> wrote:
On Wed, 2008-10-22 at 20:59 -0600, Eric Stadtherr wrote:
Content-Type: multipart/alternative; boundary="=_alternative 006F3A73872574E8_="Is there one space, two spaces or a TAB at the beginning of the second line?
I did a little bit of tracing through the parsing code (message-header-parser.c:message_parse_header_next()) and it appeared that the boundary in the Content-Type header was not parsed correctly, evidently because the header line was folded in the middle of the boundary string. RFC 822 appears to allow folding in a quoted string like this (ยง3.3 "quoted-string"), so I'm curious whether the parsing is
working correctly.
Fixed: http://hg.dovecot.org/dovecot-1.1/rev/25b0cf7c62d3
But I'm not sure if I should convert the following TAB to a space. UW-IMAP seems to do that, but RFC just says that the CRLF should be dropped.
I grabbed a snapshot of the CM baseline with that fix, but that message still doesn't display correctly. I ran it through the message_parser test case and your fix look like it resulted in correct header values and correct body parsing, but the BODYSTRUCTURE response from the server still only contains the first part (plus the boundary name).
Any suggestions where to look? I looked through the code that handles the BODYSTRUCTURE fetch command and it looked like it eventually filtered down to the same parser functions used by the test case, so I'm not sure where else the problem could be introduced...
-- Eric Stadtherr estadtherr@gmail.com