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? -- jules _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers