Re: [PATCH] Output unmodified Content-Type header value for JSON format.
authorJameson Graef Rollins <jrollins@finestructure.net>
Sat, 19 Nov 2011 01:58:52 +0000 (17:58 +1600)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:40:19 +0000 (09:40 -0800)
76/1cef28b3f45cde1c33f3d40b39b3a3f5b589db [new file with mode: 0644]

diff --git a/76/1cef28b3f45cde1c33f3d40b39b3a3f5b589db b/76/1cef28b3f45cde1c33f3d40b39b3a3f5b589db
new file mode 100644 (file)
index 0000000..fd3ae6d
--- /dev/null
@@ -0,0 +1,108 @@
+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 6BF6A429E27\r
+       for <notmuch@notmuchmail.org>; Fri, 18 Nov 2011 17:59:01 -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 Ujr--0lI+vTX for <notmuch@notmuchmail.org>;\r
+       Fri, 18 Nov 2011 17:59:00 -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 C4E12431FD0\r
+       for <notmuch@notmuchmail.org>; Fri, 18 Nov 2011 17:59:00 -0800 (PST)\r
+Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+       by earth-doxen-postvirus (Postfix) with ESMTP id 4007666E01C2;\r
+       Fri, 18 Nov 2011 17:58:58 -0800 (PST)\r
+X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new\r
+Received: from finestructure.net (DHCP-123-180.caltech.edu [131.215.123.180])\r
+       (Authenticated sender: jrollins)\r
+       by earth-doxen-submit (Postfix) with ESMTP id 62F5666E0134;\r
+       Fri, 18 Nov 2011 17:58:55 -0800 (PST)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+       id 43922ACC; Fri, 18 Nov 2011 17:58: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: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
+References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@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: Fri, 18 Nov 2011 17:58:52 -0800\r
+Message-ID: <87fwhkyisj.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: Sat, 19 Nov 2011 01:59:01 -0000\r
+\r
+--=-=-=\r
+\r
+On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:\r
+> Before the change, notmuch used g_mime_content_type_to_string(3)\r
+> function to output Content-Type header value.  Turns out it outputs\r
+> only "type/subtype" part and ignores all parameters.  Also, if there\r
+> is no Content-Type header, default "text/plain" value is used.\r
+\r
+Hi, Dmitry.  Can you explain under what circumstances you would need the\r
+extra content-type parameters?  It just seems like a lot of extra noise\r
+in the output to me, but that's partially because I can't think of any\r
+reason why something that is receiving pre-parsed mime content would\r
+need it.  Maybe there's a better way to handle what you're trying to get\r
+to.\r
+\r
+I think it would help a lot if you could submit some sort of test\r
+modification that demonstrates the issue.  This is one of the reasons we\r
+keep emphasizing that it's good to first have tests in hand that\r
+demonstrate issues before patches that address them.\r
+\r
+>   "content": [{"id": 2,\r
+> - "content-type": "text/plain",\r
+>   "content": "This is a test signed message.\n"},\r
+\r
+Without figuring out what's going on, I notice that some of the tests\r
+have been modified to remove the content-type fields on a bunch of\r
+parts.  I think that is probably not right.\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
+iQIcBAEBCAAGBQJOxw1cAAoJEO00zqvie6q8hDkP/Aum2noyxQn0lJPXu4tXfDPv\r
+FwQhuCLJOyuuSR3wtcQlZZPZ1uorY6f06J44QpjB9yAUEv5IUB9KfzbkLgpKLQJd\r
+9Cs54Bh3aTCoQLpKXyWSb2y9JoQEI4/tK1Jm98RzIA4RZ4Bg6sop+MQsTLpM5ULn\r
+3xKyCuIkKeVoO9B9unIZoWR4aBbmj8nig333MgxzT3aaXXesF0iON+WVi52rfXC5\r
+0ebBJoyY1mOJxJoUUmLJBa+2AWnGLyf7XYbl0y4x/RUPbUSGJ+O8LU3O9uLKyxSi\r
+NlBtSr/Rj/xUyOFQwnz37P7CxotqSNWpbYqEHl9G+9R2LgsJdDITOOw3Car8lWhm\r
+//f1OxW0gyPVrDDrZhplWWOID7SGQ/SWMsSXkPayYxox8ExyxJu0mg/V6x3b4Nqf\r
+SSXThr0sSpYrYYlmpZO5vI1GEIC6MrvC5pisP8dOHHb3pNEL6YVQYmYP+CwUaZux\r
+ZCyhChiWXbpkBm6tGpAoYdNbDr7Z/uwkdGKvUo0Es7s4qetCes9LhfZLslGACIRy\r
+5z7xHaQ+7C9t4XixuW1dAKBZGjImuaJFnRQRBNxZknD/oF65k7nANkpyG8EEVRZw\r
++Ffmrb+Ltio3t29ecBSj7QvJIWqTfIX9vK40VVrJPQerEB7STlKIlhYXkq54HEoE\r
+yNIIAuJvEGpATBr66aFN\r
+=tZ5D\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r