GNOME Bugzilla – Bug 428656
write_content_type() breaks malformed content-type headers
Last modified: 2010-11-21 17:07:46 UTC
Please describe the problem: Original messages have follow header: MIME-Version: 1.0 Content-Type: multipart/related; boundary="=felis-related=20070411093235=30450"; type=text/html After add any header, gmime regenerate message mime header on output and replace this with : MIME-Version: 1.0 Content-Type: multipart/related; boundary="=felis-related=20070411093235=30450"; type=text Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 86168 [details] Sample message
can you provide a sample program that illustrates this bug?
n/m, I see what the problem is... the problem is that the message is malformed. '/' can only appear within a quoted-string. as long as you change no headers, the message retains a "raw" memory snapshot of the original header block, once you add/change any header, that memory buffer is invalidated and so writing the message out afterward must regenerate the header block... anyways, most headers are written using a default internal header writer function which at most re-folds the header (since it has the unfolded header given to it by the parser at parse-time). Content-Type (and a few other structured fields) have special writer functions to do smarter folding of the headers, since they try to limit folding to higher-level syntactic breaks. The write_content_type() function in gmime-object.c is parsing the field value and then rewriting it back out based on the parsed data so that it can fold based on those higher-level syntactic breaks. Unfortunately, your sample message is broken and so it gets mis-parsed. as a work-around, you could implement your own write_content_type() function and call: g_mime_header_register_writer (object->headers, "Content-Type", my_write_content_type); for each GMimeObject contained within a message (you should only need to worry about GMimePart, GMimeMultipart, and GMimeMessagePart - don't worry about GMimeMessage objects, they don't have Content-Type headers associated with them) Your write_content_type() function might look like this: ssize_t my_write_content_type (GMimeStream *stream, const char *name, const char *value) { ssize_t nwritten; char *val; val = g_mime_utils_header_printf ("%s: %s\n", name, value); nwritten = g_mime_stream_write_string (stream, val); g_free (val); return nwritten; }
actually, looks like calling: g_mime_header_register_writer (object->headers, "Content-Type", NULL); will also work, as it will reset the header writer back to the default.
*** This bug has been marked as a duplicate of bug 635445 ***