bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mailutils] Unfolding header value


From: Alain Magloire
Subject: Re: [bug-mailutils] Unfolding header value
Date: Wed, 2 Jul 2003 17:24:16 -0400 (EDT)

> 
> > (1) in this case:
> > Received: [...]
> > What should header_get_value return ?
> 
> Hmm, I guess it should return unfolded strings. By the way, I've got
> an interesting obsevation:
> 
> $ mail
> 1 "Alexander E. Pat Sat Jun 28 14:46 [bug-inetutils] [BUG] talk (part of i
> & p
> [...]
> & h
> 1 "Alexander E. Pat Sat Jun 28 14:46 [bug-inetutils] [BUG]
> talk (part of i
> 
> Notice newline after [BUG] in the 'h' output. That's because
> the first listing was produced right after scanning the mailbox,
> and mboxscan.c *always unfolds* the header values. The 'h' command
> involved getting the header_t structure, filling in its blurb, etc.,
> and the functions from header.c *do not* unfold any headers. Thus,
> we have an inconsistency between the different parts of the library...
> 

Noted.

Yes, looking at this quickly, its seem to be the fast header implementation,
To make things quicker, some headers are cache when doing the scanning.

<rant>
By the way, my god!!! I got dizzy by just looking at the code in mboxscan.c
Is the speed gain worth such monstrosity 8-) ?
</rant>

My little free time is on the pop3 code and I'll look at this(mbox) later,
since it does not seem to be a show-stopper.



> > (2) header_get_value() is also used in imap4d etc ... to return header 
> > field values.
> >     If we fold and collapse headers, how to unfold and unduplicate(see the 
> > "Received:" case)
> 
> I believe it is not that critical. The newlines may be inserted at
> every whitespace character. For several headers (like Received), we may
> implement the widely accepted ways of folding.
> 

What is the accepted way?  For now if we unfold and collapse the headers, things
like

        header_get_value(header, "Received", ....)

will return a very very long line.  And it actually may break some MUA.

The other example is IMAP4, HEADER.FIELDS command.
I tryed with the wu-imap4d and it returns for "Received"


====================================================
a123 FETCH 2 BODY[HEADER.FIELDS (Received)]
* 2 FETCH (BODY[HEADER.FIELDS ("RECEIVED")] {521}
Received: from hub.ott.qnx.com (address@hidden [192.168.2.2]) by 
smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id QAA25547 for <address@hidden>; 
Fri, 13 Sep 2002 16:31:03 -0400
Received: from luna.pizzashack.org (h52544c185a20.ne.client2.attbi.com 
[24.147.42.69])
        by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA25694
        for <address@hidden>; Fri, 13 Sep 2002 16:30:15 -0400
Received: (from address@hidden)
        by luna.pizzashack.org (8.11.6/8.11.2) id g8DKVm621171;
        Fri, 13 Sep 2002 16:31:48 -0400

)
a123 OK FETCH completed
====================================================


The exact format stored in the mailbox.  Somehow it does not seem right if we 
return

====================================================
a123 FETCH 2 BODY[HEADER.FIELDS (Received)]
...
Received: .......... a very long line ...........................

)
a123 OK FETCH completed
====================================================

> > (3) maybe an approach is to add new methods/API to header_t to
> > handle the cases.
> 
> That's possible too.

hmmm something like
        header_get_raw_value()

The value return will have the entire thing, __including the fields__ i.e. the 
field "Received:"
will be part of the raw value.   The old
        header_get_value()

will be change to collapse/unfold the values and even multiple header entry 
like received
will be collpase in one line.

Comments?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]