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?
There is one space at the beginning of the continuation line. The parsed full_value basically looks like: [multipart/alternative; boundary="=_alternative\n 006F3A73872574E8_="]
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 always prefer strict adherence to the RFC, which says:
The process of moving from this folded multiple-line
representation of a header field to its single line represen-
tation is called "unfolding". Unfolding is accomplished by
regarding CRLF immediately followed by a LWSP-char as
equivalent to the LWSP-char.So, what you did looks good!
-- Eric Stadtherr estadtherr@gmail.com