[Top][All Lists]
[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?