Re: [gmime-devel] g_mime_object_get_header_list on first part in g_mime_message_foreach()?

[Jeffrey Stedfast <fejj gnome org>]

On 7/13/2016 12:14 PM, Daniel Kahn Gillmor wrote:
> When i pass a GMimeMessage object to g_mime_message_foreach(), it
> invokes the callback on a series of GMimePart objects, the first of
> which is the top-level message itself.  but this object is actually
> pretty strange:
>
>   a) when i call g_mime_object_get_headers() on it, i get the full list of
>      headers in a text blob.

The top-level part does this because it is kind of a hack in the sense 
that the top-level part "temporarily" has a cache of all of the original 
raw headers that were parsed because it has to keep them in the proper 
order.

Once you remove the part from the message, it loses this cache and goes 
back to just having its own headers.

the get_headers() method returns the cache (if it exists) and does not 
re-serialize the headers. THe object itself does not contain the header 
items.

>   b) when i call gmime_object_get_header_list(), though, and loop through
>      it with g_mime_object_get_header_list(), i only get the Content-Type
>      header.

Correct.

> For every object after the first in g_mime_message_foreach walk, these
> queries return the same set.  So i'm pretty confused as to why it would
> be different for the first part.
>
> I note that if i invoke g_mime_object_get_header_list() directly on the
> the GMimeMessage object, i get a GMimeHeaderList that contains all the
> headers, not just the Content-Type.  Should i be understanding the
> object differently somehow, or is this a bug?

It's a consequence of the way things work in order to maintain original 
header orderings.

It's fixable with a re-deign of the header APIs (e.g. the way I handle 
it in MimeKit), but that requires API breakage that I'm not sure is 
worth the price to be paid at this point.

>         --dkg
>
> PS i also see the same oddness when looping into an encrypted part using
>     g_mime_multipart_encrypted_decrypt() with a GMimeGpgContext -- the
>     returned GMimeObject has the same behavior as the first visited part
>     in the g_mime_message_foreach() walk.

I don't quite understand what you mean by this...

What additional headers does it have that it "shouldn't"?

Jeff