Re: [PATCH] Output unmodified Content-Type header value for JSON format.

diff --git a/84/666503f1a2b0c063c4a4d04911a80f1ba306d0 b/84/666503f1a2b0c063c4a4d04911a80f1ba306d0
new file mode 100644 (file)
index 0000000..21477a9
--- /dev/null
+++ b/84/666503f1a2b0c063c4a4d04911a80f1ba306d0
@@ -0,0 +1,138 @@
+Return-Path: <jrollins@finestructure.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 24F65429E25\r
+       for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 12:11:12 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.29\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id GDbYlBT62C0T for <notmuch@notmuchmail.org>;\r
+       Sun, 20 Nov 2011 12:11:09 -0800 (PST)\r
+Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
+       [131.215.239.19])\r
+       by olra.theworths.org (Postfix) with ESMTP id 7431F431FD0\r
+       for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 12:11:09 -0800 (PST)\r
+Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+       by earth-doxen-postvirus (Postfix) with ESMTP id E6CA766E075F;\r
+       Sun, 20 Nov 2011 12:11:08 -0800 (PST)\r
+X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new\r
+Received: from finestructure.net (cpe-76-174-136-149.socal.res.rr.com\r
+       [76.174.136.149]) (Authenticated sender: jrollins)\r
+       by earth-doxen-submit (Postfix) with ESMTP id EDAE066E0754;\r
+       Sun, 20 Nov 2011 12:10:55 -0800 (PST)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+       id 5DF73BBC; Sun, 20 Nov 2011 12:10:55 -0800 (PST)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
+       format.\r
+In-Reply-To: <87r512pru2.fsf@gmail.com>\r
+References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
+       <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>\r
+       <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>\r
+User-Agent: Notmuch/0.9+81~gd8cf814 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sun, 20 Nov 2011 12:10:52 -0800\r
+Message-ID: <87ipmewo4z.fsf@servo.finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha256; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 20 Nov 2011 20:11:12 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmai=\r
+l.com> wrote:\r
+> Yes, at least in most cases.  On the other hand, if you can make notmuch\r
+> show raw multipart part (you can, right?), then it seems natural that\r
+> notmuch provides enough information to parse it.\r
+\r
+This is kind of an unresolved issue, actually.  Currently headers are\r
+only included in the "raw" format output of an entire message.\r
+Otherwise, when raw output is requested of an individual part only the\r
+body is output.  For multipart parts, the raw format output includes all\r
+body parts concatenated together, still without any headers.\r
+\r
+This "raw" multipart output clearly doesn't really make much sense and\r
+we need to figure that out.  dkg wrote a good breakdown of the issue\r
+here:\r
+\r
+id:"4E09072A.7040906@fifthhorseman.net"\r
+\r
+However, this only for "raw" output.  It's definitely not the same as\r
+the json output.  For json the parts are all parsed by notmuch and\r
+placed into separate json elements.  The receiver is not going to do any\r
+further parsing since all the mime structure parsing has been done.\r
+\r
+We need to keep clear the distinction between "parsing" the mime\r
+structure, and "encoding" the content of the part.  Confusion seems to\r
+be coming from the fact that the Content-Type header includes\r
+information needed for both mime parsing and content encoding.  However,\r
+I don't think that means that we need to just include everything in the\r
+output.  Parameters that have to do with mime parsing should be dropped,\r
+since that information has already been used in the mime parsing and\r
+can't is no longer useful to the consumer.  It's just noise, and I don't\r
+think notmuch should be outputting useless noise.\r
+\r
+The open question seems to be how we handle the content encoding\r
+parameters.  My argument is that those should either be used by notmuch\r
+to properly encode the content for the consumer.  If that's not\r
+possible, then just those parameters needed by the consumer to decode\r
+the content should be output.\r
+\r
+> > But isn't that actually a large part of the issue?  If this patch fixes\r
+> > something that you think notmuch is doing improperly, could there not be\r
+> > a test for it?\r
+>=20\r
+> No.  It just happens to be how I found the problem.  The issue is:\r
+> notmuch JSON format mangles Content-Type header value by throwing away\r
+> useful information in some cases and adding info that was not there in\r
+> others.  Note that I do not mention any single parameter name here.  It\r
+> is a general issue, not a "charset" or "boundary" parameter issue.\r
+\r
+I'm sorry, but I still don't believe it's not possible to test for this\r
+issue.  If there's a problem that you're seeing, then you must of\r
+identified it somehow, and therefore there must be a way to test for it.\r
+\r
+jamie.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iQIcBAEBCAAGBQJOyV7NAAoJEO00zqvie6q89j8QAIwLpC2PTwk4ceoYJ9e44uSf\r
+2yJupIVV3+wpWqMsg7q0mY7ofNg367jFyMwF4iyWrm+cq+14O9tiGYJ0l+HoG9uk\r
+rSps+BNWVKCjiAE+MROgAWzF7BIwdbmClWzE9tIP/Scj5gbDGdcwTQYCapXs3U56\r
+ENnZP90DBpAkwGyPS12JqWDVhM9jjaRg38XM4OLhgwWc547AYAMjqaE15fe9U3PV\r
+gufXtv65ECkqLlPrHwdXNzJYsLaitRZTukAIePYcXl9OFW9HPa39DoDP8azU4jLj\r
+7hzPB9Gs4nPRTf5SWGUK4r/5VAszh3awSHuyAs3WQL3eZyyhsJlQaCz5qI16vt+/\r
+U8oNqzAfbkaZh9SSg35IlKjdA6jJ/devpdwo3aEUTY37bsBzti+WxuFQpLpgF3NV\r
+ZtonJGBaIDYMU67tCqt0t8rhq0IQ/fHjuT4eh6zuHVT4nnGZcCfp9CTb+qgKLOq7\r
+Wpa+OMnlldifAN18bMuu2R4SHvCSIjboIQ4ZEUtVTZKknGjfShT76SPywowun1ek\r
+FcvOFxrZfXa5cc430sSrugf0NeHPfrXDUdoMB2AoxczNYpiir+ZD4kc71Ez6fgGO\r
+yg3pLUt3XHzE6+vXqcoCoUZUbZbPeddxntP+Mo3MnP/+tEuWKGSVbFK/s7AtUzxC\r
+28dyJXd23Xx2g9T0JZbx\r
+=+r3R\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r