On Thu, 2005-01-06 at 17:52 +0800, Not Zed wrote:
>
> On Thu, 2005-01-06 at 04:26 -0500, Joe Marcus Clarke wrote:
> > I've been mildly annoyed by a change I noticed after upgrading from Evo
> > 2.0.2 to 2.0.3 for a while now. I finally got some time to investigate,
> > and found what I believe to be the cause, but I'm not sure of the
> > correct fix.
> >
> > The problem is certain automatically generated emails greater than 5120
> > bytes (IMAP_SMALL_BODY_SIZE) that do not contain Content-type headers do
> > not display any content when first clicked on in my folder list. The
> > server in question is imap-uw 2004a (it does advertise IMAP4REV1 in its
> > capabilities). However, if I click off one of these messages, then
> > click back on it, all the content is seen.
>
> Its not just 'still downloading' is it? Its supposed to do that, and
> wont show instantly.
Nope, I thought about that. Evo is idle. These messages are usually
around just 6K (big enough not to be "simple," but small enough to
download quickly).
>
> > It looks like revision 1.337.6.1 of camel-imap-folder.c is causing this.
> > Specifically, the check at line 2005:
> >
> > if (store->server_level < IMAP_LEVEL_IMAP4REV1
> > || store->braindamaged
> > || mi->size < IMAP_SMALL_BODY_SIZE
> > || (!content_info_incomplete(mi->content) && !mi->content->childs)) {
> >
> > Since there is no Content-type header, I think content_info_incomplete()
> > is returning TRUE, and thus my message is fetched in chunks. Sure
> > enough, setting CAMEL_IMAP_BRAINDAMAGED=1 corrects this problem, but I
> > don't think imap-uw is truly brain damaged. I'm wondering if
> > content_info_incomplete() can be fixed to accept such headerless
> > messages as text/plain instead of simply returning TRUE. It seems like
> > that was the intention of camel_content_type_is() (i.e. we can pass a
> > NULL CamelContentType, and camel_content_type_is() will do the right
> > thing). Thanks for any insight you can give.
>
> I dont think there's a problem in that code as such, its probably the
> code which does the downloading of parts not working properly.
I took some sniffer traces, and I'm not so sure it's a problem with
downloading. Evo downloads the size and headers as soon as it sees new
messages. Then, it uses that information to determine how it should
download the rest of the body. For these auto-generated messages
without a Content-type (usually CVS commit and bug reports), I see this
problem.
>
> But that might be the easist workaround, default simple messages to
> download the whole rather than in header then content.
Shall I create a patch, and forward it to evolution-patches?
Joe
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome FreeBSD org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
Attachment:
signature.asc
Description: This is a digitally signed message part