header field
Click on the red underlined text to get to the source
...
The first document in this set, RFC 2045draft, defines a number of header
fields, including Content-Type. The Content-Type field is used to
...
... media types. After the
type and subtype names, the remainder of the header field is simply a
set of parameters, specified in an attribute/value notation. The
ordering of parameters is not significant.
...
... MIME's Content-Type header field and media type mechanism has been
carefully designed to be extensible, and it is expected that the set
...
... and such characters are used in the body, a Content-Transfer-Encoding
header field and a corresponding encoding on the data are required in
order to transmit the body via some mail transfer protocols, such as
...
... media type parameter in the Content-Type
header field. "US-ASCII" does not indicate an arbitrary 7-bit
...
... were to be written to a file. This has been deprecated in
anticipation of a separate Content-Disposition header field, to be
defined in a subsequent RFC.
...
... actually being an RFC 822std11(-> 2822prop) message. To begin with, NO header fields
are actually required in body parts. A body part that starts with a
...
...
The only header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other header
fields may be ignored in body parts. Although they should generally
...
... The only header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other header
fields may be ignored in body parts. Although they should generally
be retained if at all possible, they may be discarded by gateways if
...
... with its own "Content-Type: image/jpeg" header field. The use of
similar syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
...
... 8bit", or "binary" is
permitted for entities of type "multipart". The "multipart" boundary
delimiters and header fields are always represented as 7bit US-ASCII
in any case (though the header fields ...
... header fields are always represented as 7bit US-ASCII
in any case (though the header fields may encode non-US-ASCII header
...
... followed by the boundary parameter value from the Content-Type header
field, optional linear whitespace, and a terminating CRLF.
...
... Content-type fields. Thus, a typical "multipart" Content-Type header
field might look like this:
...
... linear whitespace. It is then terminated by either another CRLF and
the header fields for the next part, or by two CRLFs, in which case
there are no header fields for the next part. If no Content-Type ...
... the header fields for the next part, or by two CRLFs, in which case
there are no header fields for the next part. If no Content-Type
field is present it is assumed to be "message/rfc822" in a
...
... transport and adequately documented in the Content- Transfer-Encoding
header field. However, in no event are headers (either message
headers or body part headers ...
... 822std11(-> 2822prop) message. In
particular, they frequently add, remove, or reorder header fields.
These operations are explicitly forbidden for the encapsulated
...
... US-ASCII in any case, and data within the body can still be
encoded, in which case the Content-Transfer-Encoding header field in
the encapsulated message will reflect this. Non-US-ASCII text ...
...
Thus, the second piece of a 3-piece message may have either of the
following header fields:
...
... entity, which may have
its own Content-Type header field, and thus may contain any other
data type.
...
... All of the header fields from the initial enclosing
message, except those that start with "Content-" and
...
... message, except those that start with "Content-" and
the specific header fields "Subject", "Message-ID",
...
... Encrypted", and "MIME-Version" fields, must be
appended, in order, to the header fields of the new
message. Any header fields in the enclosed message
...
... appended, in order, to the header fields of the new
message. Any header fields in the enclosed message
which do not start with "Content-" (except for the
...
...
All of the header fields from the second and any
subsequent enclosing messages are discarded by the
reassembly process.
...
...
Finally, it should be noted that the "Encrypted" header field has
been made obsolete by Privacy Enhanced Messaging (PEM ...
... message/external-body" entities MUST
include a Content-ID header field to give a unique identifier by
which to reference the data. This identifier ...
... multiline, the full command to be sent to a mail server is not
included as a parameter in the content-type header field. Instead,
it is provided as the "phantom body" when the media type is
...
... request messages that are constructed
should contain a clear indication that they were
generated automatically (e.g. in a Comments: header
field) in an attempt to resolve a MIME
"message/external-body ...
... specification of alternate character sets. Additional optional
header fields provide mechanisms for certain extensions deemed
desirable by many implementors. Finally, a number of useful media
types ...
... <"message" as defined in RFC 822std11(-> 2822prop), with all header fields optional, not starting with the specified dash-boundary, and with the delimiter not occurring anywhere in the body part. Note that the semantics of a part differ from the semantics ...