On Thu, 23 Oct 2008 19:06:19 +0300, Timo Sirainen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
