From: Bruce Lilly (blilly@erols.com)
Date: Sun Jun 08 2003 - 18:18:12 CDT
> Actually, looking at some code I wrote which read headers, it appears that
> in three programs (two reading mail), the continuation lines are read
> first, into a maxlen buffer, and then parsed.
It's unclear what is meant by "a maxlen buffer". RFC 822 imposes *no*
limit on the length of a logical header field. Nor do RFCs 1036, 2822,
733, or 724. Among those, only 2822 imposes a limit on the lines
after folding, and that limit is for generating messages, not parsing.
> So continuation is never
> even seen by the parser.
In that implementation. When header line length happens to be
less than the implementation limit.
> Given the other input on this, I would say that a space after the colon
> must (or MUST) be present, but after that continuation is allowed. Since
> whitespace on the following line will be lost in most implementations, it
> seems needed on the first line.
What is the basis for the claim regarding "most implementations" -- where
is your data that substantiates that claim? What do you mean by "lost"?
And what is the basis for requiring whitespace on the first line? An RFC 822
or 2822 (or 733, or 724) parser must be able to correctly parse fields with
no space (or indeed no linear whitespace) after the colon that delimits the
start of the field body, or with line folding immediately following that
colon, or with an HTAB instead of (or in addition to) SP, or with multiple
whitespace characters.