From 353aaf2fa136d34db64d1e4af12cc12431466a9e Mon Sep 17 00:00:00 2001 From: Kirill Smelkov Date: Thu, 8 Jan 2009 01:43:42 +0300 Subject: mailinfo: correctly handle multiline 'Subject:' header MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When native language (RU) is in use, subject header usually contains several parts, e.g. Subject: [Navy-patches] [PATCH] =?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?= =?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?= =?utf-8?b?0YHQsdC+0YDQutC4?= This exposes several bugs in builtin-mailinfo.c: 1. decode_b_segment: do not append explicit NUL -- explicit NUL was preventing correct header construction on parts concatenation via strbuf_addbuf in decode_header_bq. Fixes: -Subject: Изменён список пакетов необходимых для сборки +Subject: Изменён список па Then 2. Do not emit '\n' between "encoded-word" where RFC2046 says that linear white space between them are ignored when displaying. Fixes: -Subject: Изменён список пакетов необходимых для сборки +Subject: Изменён список па кетов необходимых для сборки Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano --- builtin-mailinfo.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) (limited to 'builtin-mailinfo.c') diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c index e890f7a6d1..fcb32c9818 100644 --- a/builtin-mailinfo.c +++ b/builtin-mailinfo.c @@ -430,13 +430,6 @@ static struct strbuf *decode_b_segment(const struct strbuf *b_seg) c -= 'a' - 26; else if ('0' <= c && c <= '9') c -= '0' - 52; - else if (c == '=') { - /* padding is almost like (c == 0), except we do - * not output NUL resulting only from it; - * for now we just trust the data. - */ - c = 0; - } else continue; /* garbage */ switch (pos++) { @@ -514,7 +507,25 @@ static int decode_header_bq(struct strbuf *it) rfc2047 = 1; if (in != ep) { - strbuf_add(&outbuf, in, ep - in); + /* + * We are about to process an encoded-word + * that begins at ep, but there is something + * before the encoded word. + */ + char *scan; + for (scan = in; scan < ep; scan++) + if (!isspace(*scan)) + break; + + if (scan != ep || in == it->buf) { + /* + * We should not lose that "something", + * unless we have just processed an + * encoded-word, and there is only LWS + * before the one we are about to process. + */ + strbuf_add(&outbuf, in, ep - in); + } in = ep; } /* E.g. -- cgit v1.2.3 From ddfb3696b91e2a2261b79d0828a7a715e3d71c1e Mon Sep 17 00:00:00 2001 From: Kirill Smelkov Date: Mon, 12 Jan 2009 15:22:11 -0800 Subject: mailinfo: 'From:' header should be unfold as well At present we do headers unfolding (see RFC822 3.1.1. LONG HEADER FIELDS) for all fields except 'From' (always) and 'Subject' (when keep_subject is set) Not unfolding 'From' is a bug -- see above-mentioned RFC link. Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano --- builtin-mailinfo.c | 1 + 1 file changed, 1 insertion(+) (limited to 'builtin-mailinfo.c') diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c index fcb32c9818..dacc8ac2d0 100644 --- a/builtin-mailinfo.c +++ b/builtin-mailinfo.c @@ -871,6 +871,7 @@ static void handle_info(void) } output_header_lines(fout, "Subject", hdr); } else if (!memcmp(header[i], "From", 4)) { + cleanup_space(hdr); handle_from(hdr); fprintf(fout, "Author: %s\n", name.buf); fprintf(fout, "Email: %s\n", email.buf); -- cgit v1.2.3