Hi Jeffrey-- On Thu 2016-07-14 04:29:59 +0200, Jeffrey Stedfast wrote:
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.
so, to be clear, the message itself is seen as distinct from the "top-level part" somehow? I've been conceptualizing them as the same thing -- that is, that the top-level part *is* the message, which is why it was surprising to me that the GMimeHeaderList of the top-level part didn't have the same sequence as the message itself.
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.
Can you describe what you think the fix would look like?
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"?
i mean the other way around -- the GMimeHeaderList extracted from the
object returned by g_mime_multipart_encrypted_decrypt() only has
content-type in it. I think it *doesn't* have the additional headers
that i'd expect it to have.
--dkg
Attachment:
signature.asc
Description: PGP signature