Re: [PATCH] Output unmodified Content-Type header value for JSON format.
authorTomi Ollila <tomi.ollila@iki.fi>
Mon, 16 Jan 2012 13:18:30 +0000 (15:18 +0200)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:42:16 +0000 (09:42 -0800)
da/e2b3b5dd96d8b07814d1d7dd69d0e830216b1a [new file with mode: 0644]

diff --git a/da/e2b3b5dd96d8b07814d1d7dd69d0e830216b1a b/da/e2b3b5dd96d8b07814d1d7dd69d0e830216b1a
new file mode 100644 (file)
index 0000000..279094e
--- /dev/null
@@ -0,0 +1,129 @@
+Return-Path: <tomi.ollila@nixu.com>\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 BB4B6429E4E\r
+       for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:18:36 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       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 BlzCo79UXJyW for <notmuch@notmuchmail.org>;\r
+       Mon, 16 Jan 2012 05:18:36 -0800 (PST)\r
+Received: from mail-gw3.nixu.fi (mail-gw3.nixu.fi [193.209.237.7])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id CD2D2429E4A\r
+       for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:18:35 -0800 (PST)\r
+Received: from pps.filterd (mail-gw3 [127.0.0.1])\r
+       by mail-gw3.nixu.fi (8.14.4/8.14.4) with SMTP id q0GDHrvV018941;\r
+       Mon, 16 Jan 2012 15:18:31 +0200\r
+Received: from taco2.nixu.fi (taco2.nixu.fi [194.197.118.31])\r
+       by mail-gw3.nixu.fi with ESMTP id 114cs15q3r-1\r
+       (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+       Mon, 16 Jan 2012 15:18:30 +0200\r
+Received: from taco2.nixu.fi (taco2.nixu.fi [194.197.118.31])\r
+       by taco2.nixu.fi (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id\r
+       q0GDIUo8003383; Mon, 16 Jan 2012 15:18:30 +0200\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: David Edmondson <dme@dme.org>, Austin Clements <amdragon@MIT.EDU>,\r
+       Pieter Praet <pieter@praet.org>\r
+Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
+       format.\r
+In-Reply-To: <cunlip858xs.fsf@hotblack-desiato.hh.sledj.net>\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
+       <87ipmewo4z.fsf@servo.finestructure.net>\r
+       <20111123034021.GL9351@mit.edu> <87ipkglui4.fsf@praet.org>\r
+       <20120112172840.GC18625@mit.edu> <87ehv2proa.fsf@praet.org>\r
+       <cun1ur16v3r.fsf@hotblack-desiato.hh.sledj.net>\r
+       <87boq4q23z.fsf@awakening.csail.mit.edu>\r
+       <cunlip858xs.fsf@hotblack-desiato.hh.sledj.net>\r
+User-Agent: Notmuch/0.11+64~g42e8f66 (http://notmuchmail.org) Emacs/23.3.1\r
+       (i686-pc-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+       $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+       !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Mon, 16 Jan 2012 15:18:30 +0200\r
+Message-ID: <yf6vcobwztl.fsf@taco2.nixu.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,\r
+ 1.0.211,      0.0.0000        definitions=2012-01-16_01:2012-01-16, 2012-01-16,\r
+       1970-01-01 signatures=0\r
+X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0\r
+       ipscore=0 suspectscore=0\r
+       phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0\r
+       reason=mlx\r
+       scancount=1 engine=6.0.2-1012030000 definitions=main-1201160097\r
+Cc: notmuch@notmuchmail.org\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: Mon, 16 Jan 2012 13:18:36 -0000\r
+\r
+On Mon, 16 Jan 2012 08:49:03 +0000, David Edmondson <dme@dme.org> wrote:\r
+> On Sun, 15 Jan 2012 12:58:40 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> \r
+> This, I suspect, brings us back to what may have been Dmitry's original\r
+> concern. If we codify the current behaviour then we're actually\r
+> _forcing_ clients to use inline content if it's present, because\r
+> otherwise they have no way to discover the charset/encoding used for the\r
+> raw part.\r
+> \r
+> That seems as though it could be a problem for some clients.\r
+> \r
+> > OTOH, I don't understand the encoding story for HTML, since the encoding\r
+> > can come from either a header or from the body of the HTML.  Does this\r
+> > make it strictly necessary for the client to handle the encoding?\r
+\r
+Either from a header or from the body of the *HTTP*. Html meta tag is part\r
+of the header of the HTML document, body of the HTTP message.\r
+\r
+> If it can be specified by the content of a part rather than the part\r
+> headers, then I think that the client will have to be prepared to handle\r
+> it.\r
+> \r
+> Even if not, it might still be more effective to choose that approach -\r
+> it would remove the need to add arbitrary encoding support to the CLI\r
+> application.\r
+\r
+In case of w3m interface if charset is not told it defaults\r
+to iso-8859-1 as both input and output encoding.\r
+\r
+That is no problem in w3m -- it just doesn't do any conversion.\r
+\r
+But emacs thinks that it gets input in iso-8859-1 format and will\r
+attempt to convert that to whatever charset the window user has\r
+is using. \r
+\r
+If input was utf8 but emacs thinks input was latin1 then we get\r
+this infamous 'double-utf8'ied output (a subset of wtf-8 charset ;)\r
+(in case window charset is utf8)\r
+\r
+In case of w3m the content feed to w3m could be pre-encoded to utf-8\r
+and w3m interface is told that charset is utf-8 -- w3m will now\r
+called using utf-8 as input and output encoding -- and at the end\r
+emacs does conversion from utf-8 to the window encoding (if needed).\r
+\r
+As mentioned in IRC: 2012-01-10 11:46 (UTC)  xxxXX  indeed, the headers\r
+       should take precedence to meta tag, as defined in HTML4\r
+\r
+So, complying clients takes the precedence from command line options\r
+(which, in case of command line clients makes perfect sense).\r
+\r
+Tomi\r