Re: [gmime-devel] change in g_object_write_to_stream w.r.t. headers

[Jeffrey Stedfast <fejj gnome org>]

Hi David,

Answers below...

On 5/21/2017 7:19 PM, David Bremner wrote:
> I have some questions about the way g_mime_object_write_to_stream
> behaves with respect to headers (I suspect this is related to the change
> in message structure alluded to in PORTING).  If the attached program is
> compiled with gmime-2.6, then the top level part has message headers
> (From, To, Subject, etc...) attached to it, while if compiled with gmime
> 3.0, only the part headers (Content-type, content-transfer-encoding) are
> included.  The new behaviour seems sensible (there are other ways to get
> the message headers), but
>
> 0) Can you confirm this change is intentional?

Sort of yes and sort of no.

A more complete answer would be that the 2.6 behavior was an unintended 
consequence of the way it cached the raw headers as one big stream on 
the GMimeHeaderList rather than on a per-header basis like 3.0 now does.

I guess you could say that the 2.6 behavior is/was a bug?

> 1) Assuming so, another note for PORTING?

Probably.

> 3) Is there a way to achieve the same output in gmime-2.6 as the new
>     output in 3.0?

This is a bit of a hack, but...

cache = g_mime_header_list_get_stream (object->headers);
g_object_ref (cache);
g_mime_header_list_set_stream (object->headers, NULL);

g_mime_object_write_to_stream (object, ostream);

g_mime_header_list_set_stream (object->headers, cache);
g_object_unref (cache);


Keep in mind that this will force GMimeHeaderList to re-format the MIME 
headers when writing out the object, so it won't necessarily be 
*exactly* the same as the 3.0 behavior, but it'll get you about as close 
as I can come up with short of writing a GMimeFilter to filter out 
headers that don't start with "Content-", but that's going to be a 
complex work-around.

Hope that helps,

Jeff