Each header field is logically a single line of characters
comprising the field name, the colon, and the field body. For
convenience however, and to deal with the 998/78 character
limitations per line, the field body portion of a header field can be
split into a multiple-line representation; this is called "folding".
The general rule is that wherever this specification allows for
folding white space (not simply WSP characters), a CRLF may be
inserted before any WSP.
For example, the header field:
Subject: This is a test
can be represented as:
Subject: This
is a test
...
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. An unfolded header field has no length restriction and
therefore may be indeterminately long.
...
White space characters, including white space used in folding
(described in section 2.2.3), may appear between many elements in
header field bodies. Also, strings of characters that are treated as
comments may be included in structured field bodies as characters
enclosed in parentheses. The following defines the folding white
space (FWS) and comment constructs.
Strings of characters enclosed in parentheses are considered
comments so long as they do not appear within a "quoted-string", as
defined in section
3.2.4. Comments may nest.
There are several places in this specification where comments and
FWS may be freely inserted. To accommodate that syntax, an
additional token for "CFWS" is defined for places where comments
and/or FWS can occur. However, where CFWS occurs in this
specification, it MUST NOT be inserted in such a way that any line
of a folded header field is made up entirely of WSP characters and
nothing else.
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
Throughout this specification, where FWS (the folding white space
token) appears, it indicates a place where folding, as discussed in
section 2.2.3, may take place. Wherever folding appears in a
message (that is, a header field body containing a CRLF followed by
any WSP), unfolding (removal of the CRLF) is performed before any
further semantic analysis is performed on that header field according
to this specification. That is to say, any CRLF that appears in FWS is
semantically "invisible".
A comment is normally used in a structured field body to provide some
human-readable informational text. Since a comment is allowed to
contain FWS, folding is permitted within the comment. Also note that
since quoted-pair is allowed in a comment, the parentheses and
backslash characters may appear in a comment, so long as they appear
as a quoted-pair. Semantically, the enclosing parentheses are not
part of the comment; the comment is what is contained between the two
parentheses. As stated earlier, the "" in any quoted-pair and the
CRLF in any FWS that appears within the comment are semantically
"invisible" and therefore not part of the comment either.
Runs of FWS, comment, or CFWS that occur between lexical tokens in a
structured header field are semantically interpreted as a single space
character.
