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

[Jameson Graef Rollins]

On Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin <dmitry.kurochkin at gmail.com> wrote:
> Yes, at least in most cases.  On the other hand, if you can make notmuch
> show raw multipart part (you can, right?), then it seems natural that
> notmuch provides enough information to parse it.

This is kind of an unresolved issue, actually.  Currently headers are
only included in the "raw" format output of an entire message.
Otherwise, when raw output is requested of an individual part only the
body is output.  For multipart parts, the raw format output includes all
body parts concatenated together, still without any headers.

This "raw" multipart output clearly doesn't really make much sense and
we need to figure that out.  dkg wrote a good breakdown of the issue
here:

id:"4E09072A.7040906 at fifthhorseman.net"

However, this only for "raw" output.  It's definitely not the same as
the json output.  For json the parts are all parsed by notmuch and
placed into separate json elements.  The receiver is not going to do any
further parsing since all the mime structure parsing has been done.

We need to keep clear the distinction between "parsing" the mime
structure, and "encoding" the content of the part.  Confusion seems to
be coming from the fact that the Content-Type header includes
information needed for both mime parsing and content encoding.  However,
I don't think that means that we need to just include everything in the
output.  Parameters that have to do with mime parsing should be dropped,
since that information has already been used in the mime parsing and
can't is no longer useful to the consumer.  It's just noise, and I don't
think notmuch should be outputting useless noise.

The open question seems to be how we handle the content encoding
parameters.  My argument is that those should either be used by notmuch
to properly encode the content for the consumer.  If that's not
possible, then just those parameters needed by the consumer to decode
the content should be output.

> > But isn't that actually a large part of the issue?  If this patch fixes
> > something that you think notmuch is doing improperly, could there not be
> > a test for it?
> 
> No.  It just happens to be how I found the problem.  The issue is:
> notmuch JSON format mangles Content-Type header value by throwing away
> useful information in some cases and adding info that was not there in
> others.  Note that I do not mention any single parameter name here.  It
> is a general issue, not a "charset" or "boundary" parameter issue.

I'm sorry, but I still don't believe it's not possible to test for this
issue.  If there's a problem that you're seeing, then you must of
identified it somehow, and therefore there must be a way to test for it.

jamie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111120/2273c8bb/attachment.pgp>