We should listen carefully to what Roy Fielding said.
A careful reading of what a "Location:" header should mean in
this context is exactly what we need. It identifies [an URI,
today an URL] by which the body may be refreshed. Under these
circumstances, the "Content-" prefix only serves to increase the
count of "RFC 822 headers of record" and should be eliminated.
Wrong. The "Content-" prefix serves a very important purpose -- it allows for
use of the header with body parts of messages rather than messages as a whole.
From RFC1521, section 7.2:
A body part is NOT to be interpreted as actually being an RFC 822
message. To begin with, NO header fields are actually required in
body parts. A body part that starts with a blank line, therefore, is
allowed and is a body part for which all default values are to be
assumed. In such a case, the absence of a Content-Type header field
implies that the corresponding body is plain US-ASCII text. The only
header fields that have defined meaning for body parts are those the
names of which begin with "Content-". All other header fields are
generally to be ignored in body parts. Although they should
generally be retained in mail processing, they may be discarded by
gateways if necessary. Such other fields are permitted to appear in
body parts but must not be depended on. "X-" fields may be created
for experimental or private purposes, with the recognition that the
information they contain may be lost at some gateways.
Unless you intend for this mechanism to only work for messages as a whole, it
has to begin with "Content-".
Ned