Re: [Evolution-hackers] camel_header_unfold()

[Jeffrey Stedfast <fejj novell com>]

On Tue, 2005-11-29 at 09:55 +0100, Jules Colding wrote:
> On Mon, 2005-11-28 at 12:12 -0500, Jeffrey Stedfast wrote:
> > I see what you are thinking, but by the time this code is run on any
> > input, the \r has already been stripped and you cannot, by definition,
> > have \n\n in a header (it terminates the header block so we don't have
> > to worry about that).
> > 
> > I suppose the following modification could be made to be more clear:
> > 
> > char *
> > camel_header_unfold(const char *in)
> > {
> > 	char *out = g_malloc(strlen(in)+1);
> > 	const char *inptr = in;
> > 	char c, *o = out;
> > 
> > 	o = out;
> > 	while ((c = *inptr++)) {
> > 		if (c == '\n') {
> > 			if (*inptr == ' ' || *inptr == '\t') {
> > 				do {
> > 					inptr++;
> > 				} while (*inptr == ' ' || *inptr == '\t');
> > 				*o++ = ' ';
> 
> Might be nitpicking, but RFC 2822 says:
> 
>    "The process of moving from this folded multiple-line representation
>    of a header field to its single line representation is called
>    "unfolding". Unfolding is accomplished by simply removing any CRLF
>    that is immediately followed by WSP.  Each header field should be
>    treated in its unfolded form for further syntactic and semantic
>    evaluation."
> 
> So it appears to me that too much is being removed above. Shouldn't the
> unfolding operation simply remove the CRLF and nothing else?

if you wanted to get nitty gritty to the finer details of the spec,
sure, but in reality it's much nicer to get rid of the extra whitespace
many clients stick in there when folding.

Often, mailers will folder "part1 part2" into "part1\n\tpart2" or "part1
\n\t part2" or sometimes even "part1\n    part2"

Anyways, if we wanted to remove the unfolding niceness, we'd simply
remove that inner loop and it'd be fixed.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com