Status
of
this
Document
This
deleted text:
draft
incorporates
comments
from
Norm
Walsh,
Rob
Lanphier,
Tim
Berners-Lee,
Stuart
Williams
and
discussion
from
the
TAG's
<a href="http://www.w3.org/2003/07/07-tag-summary.html#contentTypeOverride-24">
7
July
2003
teleconference
</a>.
</p>
<p>
This
document
has
been
developed
for
discussion
by
the
W3C
Technical
Architecture
Group
.
This
draft
finding
addresses
issue
contentTypeOverride-24
and
partly
addresses
issue
errorHandling-20
.
The
TAG
finding
"
"
Internet
Media
Type
registration,
consistency
of
use
"
"
also
includes
material
related
to
this
issue.
Publication
of
this
finding
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
Additional
TAG
findings
,
both
approved
and
in
draft
state,
may
also
be
available.
The
TAG
expects
to
incorporate
this
and
other
findings
into
a
Web
Architecture
Document
that
will
be
published
according
to
the
process
of
the
W3C
Recommendation
Track
.
The
terms
MUST,
SHOULD,
and
SHOULD
NOT
are
used
in
this
document
in
accordance
with
[RFC2119]
.
Please
send
comments
on
this
finding
to
the
publicly
archived
TAG
mailing
list
www-tag@w3.org
(
archive
).
1
Summary
of
Key
Points
The
following
are
the
key
architectural
points
of
this
finding:
-
MIME
headers
Representation
metadata
sent
by
the
originator
of
a
server
are
authoritative.
message
is
authoritative
in
respect
to
defining
the
proper
interpretation
of
the
associated
representation.
[Design
choice]
-
User
agent
Agent
behavior
that
misrepresents
the
user
or
the
server
resource
provider
is
harmful.
[Principle]
For
example,
when
an
HTTP
message
contains
a
representation
as
its
payload
(within
its
message
body),
the
HTTP
header
field
"Content-Type",
if
present,
defines
the
Internet
media
type
of
that
representation.
The
recipient
is
not
allowed
to
"guess"
the
media
type
unless
no
such
metadata
was
provided
with
the
representation.
Section
2
presents
scenarios
where
these
principles/points
have
been
ignored
and
poses
the
question
of
what
has
been
ignored
and
by
whom.
<a href="#mime-headers">
Section
3
discusses
the
motivation
for
a
Web
architecture
where
MIME
headers
are
origin
metadata
is
authoritative.
Section
4
examines
the
potential
harm
caused
by
deleted text:
user
agents
that
misrepresent
the
user
or
silently
disregard
authoritative
headers.
Section
5
discusses
the
interaction
between
metadata
hints
in
format
specifications
and
protocol
headers.
Section
6
suggests
ways
in
which
server
management
can
alleviate
some
header/content
inconsistencies.
problems
due
to
inconsistencies
between
provided
content
and
configured
metadata.
2
Scenarios
Scenario
1:
Stuart
runs
his
own
Web
server
at
<code>
http://www.example.org/
</code>.
"http://www.example.org/".
He
creates
an
HTML
page
and
means
to
serve
it
as
<code>
text/html
</code>,
"text/html",
but
misconfigures
the
origin
server
so
that
the
content
is
served
via
HTTP/1.1
[RFC2616]
as
<code>
text/plain
</code>
rather
than
as
<code>
text/html
</code>.
"text/plain".
Tim's
browser
looks
inside
the
page,
detects
some
markup
that
suggests
that
this
is
an
HTML
document
(e.g.,
a
<!DOCTYPE
declaration
or
<title>
element),
and
quietly
renders
it
according
to
the
HTML
specification
rather
than
as
plain
text.
Janet's
browser
displays
the
content
as
plain
text.
Which
party
has
neglected
a
principle
of
Web
architecture:
Stuart
for
the
server
misconfiguration,
Tim's
browser
for
silently
overriding
the
server's
headers,
or
Janet's
browser
for
not
detecting
that
the
content
looked
like
HTML?
Answer
1:
By
silently
overriding
authoritative
headers
metadata
,
Tim's
browser
did
not
respect
Web
architecture principles that promote shared understanding.
Scenario 2: Norm publishes an XHTML document that includes:
<link href="cool-style" type="text/css" rel="stylesheet"/>
<link href="cool-style" type="text/css" rel="stylesheet"/>
Norm's
"cool-style"
"cool-style"
is
an
XSLT
style
sheet,
but
Norm
has
set
type
to
<code>
text/css
</code>.
"text/css".
Stuart
has
configured
the
origin
server
so
that
"cool-style"
"cool-style"
is
served
via
HTTP/1.1
as
<code>
application/xslt+xml
</code>.
"application/xslt+xml".
With
a
user
agent
that
understands
XSLT
but
not
CSS,
Janet
requests
the
content
that
includes
this
link
element.
As
it
loads
the
page,
Janet's
user
agent
reads
the
type
hint
and
does
not
fetch
"cool-style."
"cool-style."
Which
party
is
responsible
for
the
fact
that
Janet
did
not
receive
content
she
should
have:
Stuart
for
the
server
configuration,
Norm
for
stating
that
the
"cool-style"
"cool-style"
sheet
is
served
as
<code>
text/css
</code>
"text/css"
when
in
fact
it's
served
with
a
different
content
media
type,
or
Janet's
user
agent
for
not
double-checking
the
content
media
type
with
the
server?
Answer
2:
Though
not
a
violation
of
principles
of
Web
architecture,
Norm's
mislabeling
of
content
deprived
Janet
of
content
she
should
have
received.
In
the
sections
below,
we
explore
these
answers
in
more
detail.
<a name="mime-headers" id="mime-headers">
3
Why
MIME
headers
are
metadata
from
the
resource
provider
is
authoritative
Successful
communication
between
two
parties
about
using
a
piece
of
information
relies
on
shared
understanding
of
the
meaning
of
the
information.
On
the
Web,
thousands
Arbitrary
numbers
of
independent
parties
can
identify
and
communicate
about
a
Web
resource.
To
give
these
parties
the
confidence
that
they
are
all
talking
about
the
same
thing
when
they
refer
to
"the
"the
resource
identified
by
the
following
URI
..."
..."
the
design
choice
for
the
Web
is,
in
general,
that
the
owner
provider
of
a
resource
assigns
the
authoritative
interpretation
of
its
representations.
representations
of
the
resource.
A
representation
is
an
octet
sequence
that
consists
logically
of
two
parts:
-
Representation
data:
electronic
data
about
resource
state,
expressed
in
one
or
more
formats
used
separately
or
in
combination.
-
Representation
metadata,
including
the
Internet
media
type.
In
terms
of
Web
architecture,
the
authoritative
interpretation
of
representations
is
communicated
as
follows:
-
Parties
on
the
Web
agree
to
use
URIs
to
identify
resources.
-
URI
schemes
may
specify
how
names
are
allocated
(e.g.,
the
HTTP
URI
scheme
[RFC2616]
relies
on
the
Internet
domain
name
registry).
For
these
schemes,
the
party
that
creates
a
URI
has
the
right
to
establish
the
authoritative
meaning
of
the
resource.
-
The
resource
owner
provider
communicates
the
state
of
the
resource
with
bits;
the
resource
owner's
provider's
server
exchanges
these
bits
with
the
user's
clients.
-
The
user's
clients
interpret
the
bits
according
to
specification.
Generally
the
interpretation
Interpretation
of
bits
on
the
Internet
is
governed
by
deleted text:
a
protocol
specification
(e.g.,
specifications.
The
HTTP/1.1
and
FTP).
In
the
case
of
HTTP,
that
specification
specification,
for
example,
delegates
the
interpretation
of
the
message
entity
to
a
format
specification
(e.g.,
XHTML,
CSS,
PNG,
XLink,
RDF/XML,
and
SMIL
animation),
identified
by
MIME
type.
</p>
<p>
There
are
benefits
to
allowing
different
interpretations
of
a
bag
assignment
of
deleted text:
bits
depending
on
context.
For
flexibility,
some
protocols
like
HTTP/1.1
allow
resource
owners
to
direct
the
interpretation
of
a
bag
of
bits
by
sending
metadata
along
with
the
bits.
In
HTTP/1.1
a
a
response
from
the
server
can
include
for
a
bag
of
bits
(the
"entity
body")
and
metadata
about
those
bits
message
entity
(the
deleted text:
"entity
headers",
including
Content-Type,
Content-Language,
and
Content-Encoding).
In
Web
architecture
terms,
a
bag
of
bits
plus
metadata
is
called
a
<em>
representation
</em>
of
enclosed
within
a
resource.
In
practice,
the
MIME
mechanism
defined
in
RFC2046
is
used
to
associate
a
bag
of
bits
with
metadata.
MIME
headers
are
key
message)
to
deleted text:
understanding
the
authoritative
interpretation
for
a
bag
of
bits.
</p>
<p>
This
model
does
not
imply
that
a
given
set
of
bits
can
only
be
interpreted
as
the
author
intended.
The
model
is
designed
to
<em>
enable
</em>
global
understanding
by
having
parties
agree
to
follow
a
small
set
of
rules
for
interpreting
bits
(starting
with
the
MIME
type).
Parties
may
reach
local
agreements
independently,
but
they
do
not
change
the
authoritative
interpretation
of
the
bits.
</p>
<p>
Another
benefit
of
separating
metadata
that
guides
interpretation
from
data
is
improved
efficiency.
For
instance,
when
a
server
sends
XML
data
header
fields
"Content-Encoding"
and
labels
the
data
correctly
through
MIME
headers,
a
client
can
dispatch
processing
after
rapid
inspection
of
"Content-Type",
where
the
metadata
(typically
short
strings).
It
latter's
value
is
much
more
expensive
if
the
client
has
to
start
up
defined
by
an
XML
parser
to
guess
the
content
type.
</p>
<p>
A
particularly
important
piece
of
metadata
is
the
content
Internet
media
type
header,
which
instructs
a
client
on
which
specification
to
follow
first
(e.g.,
"text/html"
or
"image/jpeg")
that,
in
order
to
interpret
turn,
identifies
a
bag
of
bits;
that
registered
data
format
specification
may
invoke
others
recursively.
For
convenience,
the
MIME
mechanism
includes
a
(e.g.,
XHTML,
CSS,
PNG,
XLink,
RDF/XML,
etc.).
The
IANA
registry
of
content
type/specification
bindings
maintained
by
the
Internet
Assigned
Numbers
Authority
<a href="#">
[IANA]
</a>.
maps
media
types
to
data
format
specifications.
For
instance,
in
the
IANA
registry,
the
content
type
<code>
text/html
</code>
"text/html"
is
associated
with
[RFC2854]
,
which
in
turn
states
that:
The
text/html
media
type
is
now
defined
by
W3C
Recommendations;
the
latest
published
version
is
[HTML401].
Thus,
by
serving
a
bag
of
bits
representation
with
content
media
type
<code>
text/html
</code>,
"text/html",
the
resource
owner
provider
declares
that
the
HTML
4.01
Recommendation
governs
the
authoritative
interpretation.
By
serving
a
bag
of
bits
representation
data
(even
HTML
bits)
data)
with
content
media
type
<code>
text/plain
</code>,
"text/plain",
the
resource
owner
provider
declares
that
[RFC2046]
and
[RFC2646]
govern
the
authoritative
interpretation.
This
is
the
first
piece
of
explaining
why
Tim's
browser
in
scenario
1
is
the
culprit.
<a name="self-describing" id="self-describing">
3.1
Self-describing
data
Multiple
interpretations
possible;
only
one
authoritative
A
sequence
The
fact
that
there
is
one
authoritative
interpretation
of
representation
data
does
not
imply
that
there
is
only
one
possible
interpretation.
The
Web's
model
is
designed
to
enable
global
understanding
by
having
parties
agree
to
follow
a
small
set
of
rules
for
interpreting
bits
(starting
with
the
media
type).
Parties
may
reach
local
agreements
independently,
but
they
do
not
change
the
authoritative
interpretation
of
the
representation
data.
3.2
Metadata
and
efficiency
One
benefit
of
using
metadata
to
guide
processing
is
improved
efficiency.
For
instance,
when
a
server
sends
XML
data
and
proper
metadata,
a
client
can
determine
the
media
type
after
rapid
inspection
of
a
short
string.
It
is
considerably
more
expensive
in
processing
time
to
start
up
an
XML
parser
to
guess
the
media
type.
3.3
Self-describing
data
Data
is
"self-describing"
"self-describing"
if
it
includes
enough
information
to
allow
two
parties
to
figure
out
how
to
interpret
it
the
same
way
establish
a
consistent
interpretation
without
additional
clues.
If
the
author
intends
for
the
data
to
be
interpreted
in
a
manner
other
than
what
is
self-described
(e.g.,
"treat
"treat
this
XML
content
as
plain
text"),
text"),
then
clarifying
metadata
is
required
(e.g.,
in
protocol
headers).
Providing
redundant
metadata
for
data
that
is
self-describing
can
lead
to
inconsistencies,
however.
Thus,
for
example,
server
managers
SHOULD
NOT
in
general
specify
the
character
encoding
for
XML
data
in
protocol
headers
since
the
data
is
self-describing.
Below
we
examine
appropriate
client
behavior
when
inconsistencies
are
detected
between
what
the
server
resource
provider
declares
the
content
media
type
to
be
through
metadata
and
any
type
information
available
by
inspection
of
the
representation
data
itself.
4
Why
deleted text:
user
agent
behavior
that
misrepresents
the
user
or
resource
provider
is
harmful
A
user
agent
represents
the
user
for
interactions
with
servers.
Misrepresentation
may
lead
to
violations
of
privacy,
security
holes,
and
just
plain
confusion.
User
agent
behavior
that
misrepresents
the
user
or
misrepresents
the
server
resource
provider
ultimately
undermines
trust
on
the
Web
and
is
thus
considered
harmful.
deleted text:
Misrepresentation
may
lead
to
violations
of
privacy,
security
holes,
and
just
plain
confusion.
Some
examples
of
potential
security
violations
include:
-
The
client
ignores
a
<code>
text/plain
</code>
header,
"Content-Type"
header
with
value
"text/plain",
detects
that
the
content
is
a
shell
script,
and
executes
the
script
on
the
user's
machine
without
the
user's
knowledge.
-
A
firewall
is
configured
to
keep
out
content
of
type
<code>
text/whatever
</code>.
"text/*".
A
client
inside
the
firewall
receives
a
piece
of
content
labeled
<code>
text/plain
</code>,
representation
with
Internet
media
type
"text/plain",
detects
that
it's
really
<code>
text/whatever
</code>,
the
representation
data
is
encoded
in
a
format
"F"
and
interprets
it
the
representation
according
to
the
<code>
text/whatever
</code>
"F"
specification.
The
client
thus
violates
the
firewall
configuration.
A
client
that
ignores
authoritative
server
headers
metadata
without
deleted text:
informing
the
user
user's
consent
undermines
the
goal
of
creating
a
shared
information
space.
In
scenario
1
,
in
terms
of
Web
architecture,
Stuart
is
innocent;
misconfiguration
of
the
server
is
not
an
architectural
error,
it's
just
a
human
error.
Instead,
Tim's
browser
is
the
culprit
since
it
misrepresents
the
server
resource
provider
by
ignoring
the
authoritative
headers,
metadata,
without
informing
Tim.
Tim's
consent.
Janet's
browser
respected
the
<code>
text/plain
</code>
header,
"Content-Type"
header
field,
and
by
doing
so,
helps
Janet
and
Stuart
detect
a
server
misconfiguration.
4.1
Examples
of
inconsistencies
Examples
of
inconsistencies
between
headers
and
a
bag
of
bits
representation
data
that
have
been
observed
on
the
Web
include:
-
The
Unicode
character
encoding
of
a
XML
content
(in
an
HTTP
message
body
(XML
document)
body)
is
inconsistent
with
metadata
from
the
value
of
the
charset
parameter
in
origin
server
about
the
message
headers.
character
encoding.
When
users
read
XML
content,
such
inconsistencies
are
quickly
detected;
these
inconsistencies
may
be
more
elusive
when
XML
is
exchanged
by
processors.
-
The
namespace
of
the
root
element
of
a
XML
content
(in
an
HTTP
message
body
(XML
document)
body)
is
inconsistent
with
metadata
from
the
value
of
origin
server
about
the
content
Internet
media
type
header
in
of
the
message
headers.
representation.
Clients
should
detect
such
inconsistencies
but
should
not
resolve
them
without
involving
the
user
(e.g.,
by
securing
permission
or
at
least
providing
notification).
Another
form
of
inconsistency
is
when
the
client
expects
a
MIME
header
to
receive
metadata
that
includes
media
type
information
and
the
server
doesn't
send
one.
does
not
provide
this
information.
For
instance,
HTTP/1.1
[RFC2616]
,
section
7.2.1
describes
client
behavior
in
the
case
when
the
server
sends
no
content
type
header:
media
type:
Any
HTTP/1.1
message
containing
an
entity-body
SHOULD
include
a
Content-Type
"Content-Type"
header
field
defining
the
media
type
of
that
body.
If
and
only
if
the
media
type
is
not
given
by
a
Content-Type
"Content-Type"
field,
the
recipient
MAY
attempt
to
guess
the
media
type
via
inspection
of
its
content
and/or
the
name
extension(s)
of
the
URI
used
to
identify
the
resource.
If
the
media
type
remains
unknown,
the
recipient
SHOULD
treat
it
as
type
application/octet-stream
.
This
excerpt
is
consistent
with
the
principle
that
metadata
from
the
content
type
header,
when
present,
origin
server
is
authoritative.
authoritative
when
present
.
HTTP/1.1
allows
a
client
to
guess
when
no
content
type
is
present;
in
this
case,
content
that
is
self-describing
is
likely
to
lead
to
a
coherent
interpretation.
</p>
<p>
For
this
reason,
servers
should
only
supply
a
character
encoding
header
when
there
is
complete
certainty
as
to
the
encoding
in
use.
Otherwise,
an
error
will
cause
a
perfectly
usable
representation
to
be
rejected
by
an
architecturally
sound
client.
Section
7.1
of
<a href="#rfc3023">
[RFC3023]
</a>
states:
</p>
<div class="notice">
The
use
of
the
charset
parameter
is
STRONGLY
RECOMMENDED,
since
this
information
can
be
used
by
XML
processors
to
determine
authoritatively
the
charset
of
the
XML
MIME
entity.
</div>
<p>
However,
a
receiving
application
can,
with
very
high
reliability,
determine
the
character
encoding
of
an
XML
document
by
reading
it,
without
reference
to
any
external
headers
and
this
is
reflected
by
RFC
3023
in
section
8.9,
8.10,
and
8.11.
Thus
there
is
no
ambiguity
when
the
character
encoding
header
is
omitted,
and
the
STRONGLY
RECOMMENDED
injunction
to
use
the
character
encoding
guess
when
no
"Content-Type"
header
is
misplaced
for
<code>
application/xml
</code>
and
for
non-text
<code>
+xml
</code>
types.
</p>
<p>
We
recommend
present;
in
this
case,
representation
data
that
section
7.1
<a href="#rfc3023">
[RFC3023]
</a>
be
amended
is
self-describing
is
likely
to
something
like
the
following:
lead
to
a
consistent
interpretation
among
multiple
parties.
deleted text:
<div class="notice">
Servers
which
generate
representations
MUST
NOT
generate
the
charset
parameter
unless
there
is
certainty
that
the
headers
are
correct.
When
correct,
this
information
can
be
used
by
non-XML
processors
to
determine
authoritatively
the
character
encoding
of
the
XML
MIME
entity.
4.1
4.2
Client
handling
of
inconsistencies
In
the
absence
of
header
information,
metadata
from
the
origin
server,
a
flexible
client
would
do
even
more
than
merely
guess
and
silently
proceed.
For
instance,
in
different
configurations
the
client
could:
-
Remain
silent
when
forced
to
guess,
or
-
Inform
the
user
that
a
guess
has
been
made,
or
-
Allow
the
user
to
direct
the
client's
processing
of
the
bag
of
bits
representation
data
(e.g.,
by
invoking
a
particular
handler
or
saving
to
disk).
In
Scenario
2
,
Norm
is
responsible
for
Janet
not
having
access
to
content
she
was
meant
to
receive.
The
HTML
4.01
Recommendation
states
that
"Authors
"Authors
who
use
[the
type
]
attribute
take
responsibility
to
manage
the
risk
that
it
may
become
inconsistent
with
the
content
available
at
the
link
target
address."
address."
Janet's
client
could
have
done
more
than
merely
read
the
type
hint
and
decide
to
skip
the
"cool-style."
"cool-style."
Users
benefit
from
clients
that
allow
different
configurations
for
handling
hints,
including:
-
deleted text:
Silently
follow
hints,
or
</li>
<li>
Query
the
server,
and
when
there
is
an
inconsistency,
follow
choose
the
(authoritative)
server
heading,
metadata,
or
-
Query
the
server,
and
when
there
is
an
inconsistency,
prompt
the
user
for
instructions
on
how
to
proceed.
It
is
not
a
violation
of
Web
architecture
when
a
client
overrides
server
headers
metadata
and
processes
a
bag
of
bits
representation
data
in
a
non-authoritative
manner,
as
long
as
the
client
is
not
misrepresenting
the
user
or
server.
resource
provider.
For
instance,
an
application
does
not
violate
Web
architecture
when
it
receives
a
content
"Content-Type"
header
of
<code>
text/html
</code>
"text/html"
and,
rather
than
following
the
HTML
4.01
Recommendation,
provides
the
service
of
validating
the
HTML,
detecting
broken
links,
converting
it
to
another
format,
or
rendering
it
as
plain
text.
The
problem
arises
when
the
user
agent
engages
in
non-authoritative
behavior
without
the
user's
awareness
or
consent.
5
Hints
in
specifications
Some
format
specifications
allow
authors
to
include
in
content
"hints"
"hints"
for
servers
and
clients.
For
instance,
the
http-equiv
attribute
of
the
HTML
meta
element
is
was
intended
for
servers
(not
clients).
In
HTML
2.0
[RFC1866]
,
section
5.2.5,
the
attribute
is
specified
as
follows:
HTTP
servers
may
read
the
content
of
the
document
<head>
to
generate
header
fields
corresponding
to
any
elements
defining
a
value
for
the
attribute
HTTP-EQUIV.
The
HTML
4.01
attribute
type
for
the
link
element
(used
in
Scenario
2
)
gives
clients
a
hint
about
what
the
content
media
type
of
a
representation
of
the
linked
resource
is
likely
to
be.
A
format
specification
that
includes
hints
for
clients
should
make
clear
that
when
these
hints
interact
with
server
headings,
metadata,
they
are
advisory
only.
Format
specifications
should
not
SHOULD
NOT
include
requirements
for
clients
to
override
server
headers
metadata
without
user
consent.
An
architecturally
sound
description
of
an
advisory
attribute
might
read:
A
URI
reference
MAY
be
accompanied
by
a
media
type
that
provides
a
hint
to
the
client
about
the
likely
media
type
of
representations
of
the
designated
resource.
Although
the
client
MUST
treat
deleted text:
headers
from
the
server
metadata
(including
those
that
provided
by
the
file
system)
as
authoritative,
the
client
MAY
use
the
hint
in
a
number
of
ways,
including
as
a
preference
when
negotiating
with
the
server,
as
input
to
a
decision
to
retrieve
a
representation,
or
to
recover
from
a
misconfigured
server.
However,
deleted text:
when
the
client
does
MUST
NOT
override
the
server's
headers
(by
using
the
hint
or
any
other
mechanism),
the
client
MUST
inform
mechanism)
without
the
user
and
SHOULD
allow
consent
of
the
user
to
control
processing.
user.
The
W3C
Recommendation
SMIL
2.0
[SMIL20]
is
outmoded
consistent
with
the
current
finding
in
this
regard
since
the
definition
of
the
type
attribute
(
section
7.3.1
)
specifies
circumstances
in
which
type
is
supposed
to
take
precedence
over
server
headers.
metadata.
6
Handling
misconfigured
servers
The
rationale
frequently
provided
by
specification
designers
for
why
the
author
should
be
able
to
override
server
headers
metadata
in
content
is
to
work
around
misconfigured
servers.
In
many
environments,
authors
do
not
have
sufficient
access
to
server
managers
to
request
that
the
affect
server
be
configured
for
a
new
or
special
MIME
type.
configuration.
The
TAG
does
not
believe
that
author-specified
overrides
is
are
the
proper
solution
to
this
problem
(for
the
reasons
cited
above,
including
security
risks
and
masking
of
the
problem).
Instead
the
TAG
recommends
Server
managers
can
help
reduce
the
following
(in
addition
to
<a href="#client-behavior">
suggested
client
behavior
</a>
):
risk
of
error
through
careful
assignment
of
representation
metadata
(especially
that
which
applies
across
representations).
In
particular:
-
Server
managers
software
designers
SHOULD
NOT
specify
a
default
content
Internet
media
type
in
the
default
configuration
shipped
with
the
server.
-
Server
managers
SHOULD
be
wary
of
specifying
a
default
Internet
media
type.
-
Server
managers
SHOULD
NOT
specify
an
arbitrary
content
Internet
media
type
(e.g.,
<code>
text/plain
</code>
"text/plain"
or
<code>
application/octet-stream
</code>
)
"application/octet-stream")
when
the
content
Internet
media
type
is
unknown.
-
Authors
SHOULD
inform
server
managers
of
server
misconfigurations.
-
Server
managers
SHOULD
provide
authors
with
a
means
to
override
global
server
settings
when
those
settings
are
incorrect;
correction
of
global
server
settings
is
preferred.
7
Conclusion
-
Client
behavior
that
misrepresents
the
user
or
server
resource
provider
is
harmful.
Client
behavior
that
involves
the
user
in
decisions
about
handling
inconsistencies
or
errors
is
beneficial.
-
Since
server
headers
are
authoritative,
a
client
MUST
NOT
ignore
or
override
them
without
involving
the
user.
8
Future
Work
-
The
TAG
is
working
with
the
authors
of
[RFC3023]
to
revise
section
7.1
of
that
RFC,
which
suggests
behavior
regarding
character
encoding
metadata
that
is
inconsistent
with
the
current
finding.
-
Reviewers
of
this
finding
asked
whether
similar
architectural
principles
apply
to
headers
sent
in
the
direction
of
client
to
the
server.
This
is
the
TAG's
issue
putMediaType-38
:
"Relation
"Relation
of
HTTP
PUT
to
GET,
and
whether
client
headers
to
server
are
authoritative."
authoritative."
9
References
-
IANA
-
Internet
Assigned
Numbers
Authority
(IANA)
(See
http://www.iana.org/.)
-
RFC1866
-
T.
Berners-Lee,
D.
Connolly
Hypertext
Markup
Language
-
2.0
,
RFC1866,
November
1995.
(See
http://www.ietf.org/rfc/rfc1866.)
-
RFC2046
-
N.
Freed,
N.
Borenstein
Multipurpose
Internet
Mail
Extensions
(MIME)
Part
Two:
Media
Types
,
RFC2046,
November
1996.
(See
http://www.ietf.org/rfc/rfc2046.txt.)
-
RFC2119
-
S.
Bradner
Key
words
for
use
in
RFCs
to
Indicate
Requirement
Levels
,
RFC2119,
March
1997.
(See
http://www.ietf.org/rfc/rfc2119.txt.)
-
RFC2616
-
R.
Fielding,
J.
Gettys,
J.
Mogul,
H.
Frystyk,
L.
Masinter,
P.
Leach,
T.
Berners-Lee
Hypertext
Transfer
Protocol
--
HTTP/1.1
,
RFC2616,
June
1999.
(See
http://www.ietf.org/rfc/rfc2616.txt.)
-
RFC2646
-
The
Text/Plain
Format
Parameter
,
RFC2646,
August
1999.
(See
http://www.ietf.org/rfc/rfc2646.txt.)
-
RFC2854
-
D.
Connolly,
L.
Masinter
The
'text/html'
Media
Type
,
RFC2854,
June
2000.
(See
http://www.ietf.org/rfc/rfc2854.txt.)
-
RFC3023
-
M.
Murata,
S.
St.
Laurent,
D.
Kohn
XML
Media
Types
,
RFC3023,
January
2001.
(See
http://www.ietf.org/rfc/rfc3023.txt.)
-
SMIL20
-
J.
Ayars
et
al.
Synchronized
Multimedia
Integration
Language
(SMIL
2.0)
,
W3C
Recommendation,
7
August
2001.
(See
http://www.w3.org/TR/2001/REC-smil20-20010807/.)
10
Acknowledgments
Dan
Connolly
generously
provided
significant
input
to
this
finding.
Martin
Dürst,
Roy
Fielding,
Philipp
Hoschka,
Rob
Lanphier,
Stuart
Williams,
deleted text:
Norm
Walsh,
and
Rob
Lanphier
Norm
Walsh
also
provided
valuable
input.
Many
thanks
to
all
reviewers
for
their
contributions
to
this
finding.