Copyright
© 2008
© 2009
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This document is an editors' copy that has no official standing.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
http://www.w3.org/TR/
.
This document reflects group resolutions on comments received on the previous Last Call Working Draft .
Publication as a Group Working Draft of a proposed normative Recommendation 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. It is inappropriate to cite this document as other than work in progress.
This
document
has
been
produced
by
the
Content
Transformation
Task
Force
of
the
Mobile
Web
Best
Practices
Working
Group
as
part
of
the
Mobile
Web
Initiative
.
Please
send
comments
on
this
document
to
the
Working
Group's
public
email
list
public-bpwg-ct@w3.org
,
a
publicly
archived
mailing
list
.
This
document
was
produced
under
the
5
February
2004
W3C
Patent
Policy
.
.
W3C
maintains
a
public
list
of
patent
disclosures
made
in
connection
with
this
document;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
with
respect
to
this
specification
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
1
Introduction
(Non-Normative)
1.1
Purpose
1.2
Audience
1.3
Scope
1.4
Principles
1.4.1
IAB
Considerations
1.4.2
Priority
of
Intention
2
Terminology
(Normative)
2.1
Types
of
Proxy
2.2
Types
of
Transformation
2.3
Interpretation
of
RFC
2119
Key
Words
3
Requirements
Conformance
(Normative)
3.1
Summary
Classes
of
Requirements
Product
3.2
Control
of
the
Behavior
of
the
Proxy
3.2.1
Control
by
the
User
3.2.2
Control
by
Server
Normative
and
Informative
Parts
3.2.3
Control
by
Administrative
or
Other
Arrangements.
3.3
Normative
Language
for
Conformance
Requirements
3.2.4
Resolving
Conflicting
Instructions
3.4
Transformation
Deployment
Conformance
4
Behavior
of
Components
(Normative)
4.1
Proxy
Treatment
Forwarding
of
Request
4.1.1
no-transform
directive
in
Request
Applicable
HTTP
Methods
4.1.2
Proxy
Decision
to
Transform
no-transform
directive
in
Request
4.1.3
Proxy
Indication
Treatment
of
its
Presence
to
Server
Requesters
that
are
not
Web
browsers
4.1.4
Serving
Cached
Responses
4.1.5
Altering
Alteration
of
HTTP
Header
Field
Values
4.2
Server
Response
to
Proxy
4.1.5.1
Content
Tasting
4.3
4.1.5.2
Avoiding
"Request
Unacceptable"
Responses
4.1.5.3
User
Selection
of
Restructured
Experience
4.1.5.4
Sequence
of
Requests
4.1.5.5
Original
Header
Fields
4.1.6
Additional
HTTP
Header
Fields
4.1.6.1
Proxy
Receipt
and
Forwarding
Treatment
of
Response
from
Server
Via
Header
Field
4.4
4.2
Proxy
Forwarding
of
Response
to
User
Agent
4.2.1
Applicable
Responses
4.2.2
User
Preferences
4.2.3
Receipt
of
Cache-Control:
no-transform
4.2.4
Use
of
Cache-Control:
no-transform
4.2.5
Server
Rejection
of
HTTP
Request
4.2.6
Receipt
of
Vary
HTTP
Header
Field
4.2.7
Link
to
"handheld"
Representation
4.2.8
WML
Content
4.2.9
Proxy
Decision
to
Transform
4.2.9.1
Alteration
of
Response
4.2.9.2
Link
Rewriting
4.2.9.3
HTTPS
Link
Rewriting
5
Testing
(Normative)
A
References
B
Conformance
Statement
C
Internet
Content
Types
associated
with
Mobile
Content
D
DOCTYPEs
Associated
with
Mobile
Content
E
URI
Patterns
Associated
with
Mobile
Web
Sites
F
Summary
of
User
Preference
Handling
G
Example
Transformation
Interactions
(Non-Normative)
G.1
Basic
Content
Tasting
by
Proxy
G.2
Optimization
based
on
Previous
Server
Interaction
G.3
Optimization
based
on
Previous
Server
Interaction,
Server
has
Changed
its
Operation
G.4
Server
Response
Indicating
that
this
Representation
is
Intended
for
the
Target
Device
G.5
Server
Response
Indicating
that
another
Representation
is
Intended
for
the
Target
Device
H
Informative
Guidance
for
Origin
Servers
(Non-Normative)
H.1
Server
Response
to
Proxy
H.1.1
Use
of
HTTP
406
Status
H.1.2
Use
of
HTTP
403
Status
H.1.3
Server
Origination
of
Cache-Control:
no-transform
H.1.4
Varying
Representations
H.1.4.1
Use
of
Vary
HTTP
Header
Field
H.1.4.2
Indication
of
Intended
Presentation
Media
Type
of
Representation
I
Applicability
to
Transforming
Solutions
which
are
Out
of
Scope
(Non-Normative)
J
Scope
for
Future
Work
(Non-Normative)
B.1
J.1
POWDER
B.2
J.2
link
HTTP
Header
Field
B.3
Amendments
to
HTTP
J.3
Sources
of
Device
Information
B.4
J.4
Inter
Proxy
Communication
C
Acknowledgments
J.5
Amendment
to
and
Refinement
of
HTTP
K
Acknowledgments
(Non-Normative)
The
overall
objective
of
this
document
is
to
provide
a
means,
as
far
as
is
practical,
for
users
to
be
provided
with
at
least
a
"functional
user
experience"
[Device
Independence
Glossary]
of
the
Web,
when
mobile,
taking
into
account
the
fact
that
an
increasing
number
of
content
providers
create
experiences
specially
tailored
to
the
mobile
context
which
they
do
not
wish
to
be
altered
by
third
parties.
Equally
it
takes
into
account
the
fact
that
there
remain
a
very
large
number
of
Web
sites
that
do
not
provide
a
functional
user
experience
when
perceived
on
many
mobile
devices.
The
document
describes
how
the
origin
server
may
request
conforming
transforming
proxies
not
to
alter
HTTP
requests
and
responses,
as
well
as
describing
control
options
that
a
transforming
proxy
offers
users.
A
more
extensive
discussion
of
the
requirements
for
these
guidelines
can
be
found
in
"Content
Transformation
Landscape"
[CT
Landscape]
.
The
BPWG
W3C
Mobile
Web
Best
Practices
Working
Group
(BPWG)
is
not
chartered
to
create
new
technology,
technology
-
its
role
is
to
advise
on
best
practice
for
use
of
existing
technology.
In
satisfying
Content
Transformation
requirements,
existing
HTTP
headers,
header
fields,
directives
and
behaviors
must
be
respected,
and
as
far
as
is
practical,
no
extensions
to
[RFC
2616
HTTP]
are
to
be
used.
The recommendations in this document refer to interactions of a proxy and do not refer to any presumed aspects of the internal operation of the proxy. For this reason, the document does not discuss use of "allow" and "disallow" lists (though it does discuss behavior that is induced by the implementation of such lists). In addition it does not discuss details of how transformation is carried out except if this is reflected in interoperability. For this reason, it does not discuss the insertion or insertion of headers and footers or any other specific behaviors (though it does discuss the need for essential user interaction of some form).
The BPWG made reference to Internet Architecture Board (IAB) work on "Open Pluggable Edge Services" [RFC 3238 OPES] for various principles that underlie behavior of proxies. In this work the IAB expressed its concerns about privacy, control, monitoring, and accountability of such services.
Alteration of HTTP requests and responses is not prohibited by HTTP other than in the circumstances referred to in [RFC 2616 HTTP] Section 13.5.2 and Section 14.9.5 .
HTTP defines two types of proxy: transparent proxies and non-transparent proxies. As discussed in [RFC 2616 HTTP] Section 1.3, Terminology :
[
Definition
:
"A
transparent
proxy
is
a
proxy
that
does
not
modify
the
request
or
response
beyond
what
is
required
for
proxy
authentication
and
identification."]
[
identification.
Definition
:
"A
A
non
transparent
non-transparent
proxy
is
a
proxy
that
modifies
the
request
or
response
in
order
to
provide
some
added
service
to
the
user
agent,
such
as
group
annotation
services,
media
type
transformation,
protocol
reduction,
or
anonymity
filtering.]
filtering.
Except
where
either
transparent
or
non-transparent
behavior
is
explicitly
stated,
the
HTTP
proxy
requirements
apply
to
both
types
of
proxies."
This
document
elaborates
the
behavior
of
non
transparent
non-transparent
proxies,
when
used
for
Content
Transformation
in
the
context
discussed
in
[CT
Landscape]
.
Editorial
Note:
The
BPWG
requests
feedback
on
the
degree
to
which
it
is
necessary
to
distinguish
between
Content
Transformation
proxies
that
interact
with
user
agents
using
HTTP,
and
other
types
of
arrangements
where
a
(proprietary)
client
application
interacts
with
an
in-network
component
using
other
techniques.
There are three classes of operation on responses:
[
Definition
:
Restructuring
content
is
a
process
whereby
the
original
layout
is
altered
so
that
content
is
added
or
removed
or
where
the
spatial
or
navigational
relationship
of
parts
of
content
is
altered,
e.g.
by
linearization
(i.e.
reordering
presentation
elements,
especially
tables,
so
that
they
fit
on
a
narrow
display
and
can
be
traversed
without
horizontal
scrolling)
or
pagination.
pagination
(i.e.
splitting
a
document
too
large
to
be
stored
in
or
transmitted
to
the
terminal
in
one
piece,
so
that
it
can
be
nevertheless
accessed
by
browsing
through
a
succession
of
smaller
interlinked
documents).
It
includes
also
includes
rewriting
of
URIs
so
that
subsequent
requests
route
are
routed
via
the
proxy.]
proxy
handling
the
response.
[
Definition
:
Recoding
content
is
a
process
whereby
the
layout
of
the
content
remains
the
same,
but
details
of
its
encoding
may
be
altered.
Examples
include
re-encoding
HTML
as
XHTML,
correcting
invalid
markup
in
HTML,
conversion
of
images
between
formats
(but
not,
for
example,
reducing
animations
to
static
images).
]
[
Definition
:
Optimizing
content
includes
removing
redundant
white
space,
re-compressing
images
(without
loss
of
fidelity)
and
compressing
for
transfer.]
transfer.
A
Transformation
Deployment
is
the
provision
of
The
interactions
non-transparent
components
in
the
path
of
several
transformation
proxies
HTTP
requests
and
responses.
Provisions
that
are
encompassed
by
applicable
to
a
Transformation
Deployment
are
identified
in
this
document,
but
only
document
by
use
of
the
term
"transforming
proxy"
or
"proxy"
in
a
rudimentary
form.
the
singular
or
plural.
The
user
agent
needs
to
be
able
to
tell
Normative
parts
of
this
document
are
identified
by
the
Content
Transformation
proxy
and
use
of
"(Normative)"
following
the
origin
server:
section
name.
Informative
parts
are
identified
by
use
of
"(Non-Normative)"
following
the
section
name.
The
Content
Transformation
proxy
needs
to
be
able
to
tell
key
words
must
,
must
not
,
required
,
shall
,
shall
not
,
should
,
should
not
,
recommended
,
not
recommended
,
may
,
and
optional
in
this
Recommendation
have
the
origin
server:
meaning
defined
in
[RFC
2119]
.
that
the
request
headers
have
been
altered
(e.g.
additional
content
types
inserted).
The
origin
server
needs
to
be
able
to
tell
the
Content
A
Transformation
proxy:
that
it
varies
its
presentation
according
to
device
type
and
other
factors;
that
it
is
permissible
(or
not)
Deployment
conforms
to
perform
Content
Transformation
of
various
kinds;
that
these
guidelines
if
it
has
media-specific
representations;
that
is
unable
or
unwilling
to
deal
with
follows
the
request
statements
in
its
present
form.
The
Content
3.4
Transformation
proxy
needs
to
be
able
to
tell
the
user
agent:
Deployment
Conformance
,
that
it
has
applied
transformations
4.1
Proxy
Forwarding
of
various
kinds
to
the
content.
The
Content
Transformation
proxy
needs
to
be
able
to
interact
with
the
user:
Request
to
allow
the
user
to
disable
its
features;
,
to
alert
the
user
to
the
fact
that
it
has
transformed
content
and
to
allow
access
to
an
untransformed
representation
4.2
Proxy
Forwarding
of
the
content.
Response
to
User
Agent
3.2
Control
of
the
Behavior
of
the
Proxy
and
5
Testing
(Normative)
.
A
transforming
proxy
as
described
in
this
document
Transformation
Deployment
that
wishes
to
claim
conformance
must
offer
make
available
a
level
of
control
to
users
and
to
origin
servers
with
which
it
communicates.
conformance
statement
B
Conformance
Statement
3.2.1
Control
by
that
specifies
the
User
Transforming
proxies
reasons
for
non-compliance
with
any
clauses
containing
the
key
words
"
should
provide
"
and
"
should
not
",
"
recommended
"
and
"
not
recommended
".
Conformance
statements
must
be
sent
to
their
users:
public-content-transformation-conformance@w3.org
.
Public
archives
of
this
list
may
be
found
at
http://lists.w3.org/Archives/Public/public-content-transformation-conformance/
.
Allow
and
disallow
lists
generally
cause
intractable
problems
for
content
providers
since
there
If
the
HTTP
method
is
no
mechanism
for
them
altered
from
HEAD
to
establish
which
lists
they
GET,
proxies
should
be
on,
nor
any
generic
mechanism
though
which
they
can
check
or
change
their
status.
3.2.4
Resolving
Conflicting
Instructions
There
(providing
such
action
is
in
accordance
with
normal
HTTP
caching
rules)
cache
the
possibility
for
conflict
between
the
desires
of
the
content
provider
and
the
desires
of
users
of
response
so
that
content.
This
document
sets
out
to
provide
a
framework
within
which,
second
GET
request
for
matters
of
presentation,
the
desires
of
the
same
content
provider
are
usually
accommodated
but,
where
necessary,
the
user
may
expressly
override
those
desires
with
their
preferences.
4
Behavior
of
Components
is
not
required
(see
also
4.1.4
Serving
Cached
Responses
4.1
Proxy
Treatment
of
Request
).
Other than to convert between HEAD and GET proxies must not alter request methods.
no-transform
directive
in
Request
If
the
request
contains
a
Cache-Control:
no-transform
directive
the
proxy
directive,
proxies
must
not
forward
alter
the
request
unaltered
to
the
server,
other
than
to
comply
with
transparent
HTTP
behavior
and
defined
in
particular
[RFC
2616
HTTP]
sections
section
14.9.5
and
section
13.5.2
and
to
add
a
Via
header
fields
as
described
in
4.1.6
Additional
HTTP
header.
Header
Fields
below.
Note:
An
example
of
the
use
of
Cache-Control:
no-transform
is
the
issuing
of
asynchronous
HTTP
requests,
perhaps
by
means
of
XMLHttpRequest
[XHR]
,
which
may
include
such
a
directive
in
order
to
prevent
transformation
of
both
the
request
and
the
response.
If
there
is
no
no-transform
directive
present
Aside
from
the
usual
caching
procedures
defined
in
[RFC
2616
HTTP]
,
in
some
circumstances,
proxies
may
paginate
responses
and
where
this
is
the
case
a
request
may
be
for
a
subsequent
page
of
a
previously
requested
resource.
In
this
case
proxies
may
for
the
proxy
sake
of
consistency
of
representation
serve
stale
data
but
when
doing
so
should
analyze
whether
it
intends
to
offer
transformation
services
by
referring
to:
any
knowledge
it
has
of
notify
the
user
preferences;
that
this
is
the
case
and
must
provide
a
simple
means
of
retrieving
a
fresh
copy.
any
prior
knowledge
it
has
of
server
behavior,
derived
Aside
from
previous
interaction
with
the
server
-
and
usual
procedures
defined
in
particular
to
preserve
the
consistency
of
user
experience
across
a
sequence
of
related
requests;
[RFC
2616
HTTP]
proxies
should
not
modify
the
HTTP
method
values
of
header
fields
other
than
the
request.
User-Agent
,
Accept
,
Accept-Charset
,
Accept-Encoding
,
and
Accept-Language
header
fields
and
must
not
delete
header
fields.
It
must
be
possible
for
the
server
to
reconstruct
the
original
User
Agent
originated
header
fields
by
copying
directly
from
the
corresponding
X-Device
header
field
values
(see
4.1.5.5
Original
Header
Fields
).
Proxies
Other
than
to
comply
with
transparent
HTTP
operation,
proxies
should
not
alter
HTTP
requests
unless:
modify
any
request
header
fields
unless
one
of
the
following
applies:
unaltered
headers
the
user
would
be
prohibited
from
accessing
content
as
a
result
in
of
the
user's
request
being
rejected
by
server
responding
that
the
origin
server;
an
unaltered
request
body
is
not
consistent
with
the
origin
server's
requirements
in
respect
"unacceptable"
(see
4.2.5
Server
Rejection
of
Internet
content
type
or
character
encoding
(as
may
happen,
for
example,
if
the
proxy
has
transformed
an
HTML
form
that
results
in
this
request);
HTTP
Request
);
the
user
has
specifically
requested
a
restructured
version
desktop
experience
(see
4.1.5.3
User
Selection
of
Restructured
Experience
);
the
request
is
part
of
a
desktop
presentation.
sequence
of
requests
to
the
same
Web
site
and
either
it
is
technically
infeasible
not
to
adjust
the
request
because
of
earlier
interaction,
or
because
doing
so
preserves
consistency
of
user
experience.
These circumstances are detailed in the following sections.
Note:
Rejection
In
this
section,
the
concept
of
a
request
by
a
server
"Web
site"
is
taken
to
mean
both
a
HTTP
406
Status
as
well
used
(rather
than
"origin
server")
as
HTTP
200
Status,
with
content
indicating
that
some
origin
servers
host
many
different
Web
sites.
Since
the
request
cannot
be
handled
-
e.g.
"Your
browser
concept
of
"Web
site"
is
not
supported"
strictly
defined,
proxies
should
use
heuristics
including
comparisons
of
domain
name
to
assess
whether
resources
form
part
of
the
same
"Web
site".
Note:
The
BPWG
is
studying
heuristics
for
URI
referred
to
in
the
request
plays
no
part
in
determining
when
a
response
with
a
200
Status
should
be
treated
as
a
response
with
a
406
Status.
whether
or
not
to
alter
HTTP
request
header
field
values.
In
particular
the
patterns
mentioned
in
4.2.9
Proxy
Decision
to
Transform
are
not
material.
A
transforming
proxy
may
convert
reissue
a
HEAD
request
into
with
altered
HTTP
header
field
values
if
a
GET
previous
request
if
it
requires
the
response
body
to
determine
the
characteristics
of
with
unaltered
values
resulted
in
the
transformed
response
that
it
would
return
were
origin
server
rejecting
the
user
agent
subsequently
to
issue
a
GET
request
for
that
content.
In
this
case,
the
as
"unacceptable"
(see
4.2.5
Server
Rejection
of
HTTP
Request
).
A
proxy
should
(providing
such
action
is
may
apply
heuristics
of
various
kinds
to
assess,
in
accordance
with
normal
HTTP
caching
rules)
cache
advance
of
sending
unaltered
header
field
values,
whether
the
response
so
that
it
is
not
required
to
send
a
second
GET
request
is
likely
to
the
server.
If,
as
cause
a
result
of
carrying
out
"request
unacceptable"
response.
If
it
determines
that
this
analysis
the
proxy
remains
unaware
of
the
server's
preferences
and
capabilities
is
likely
then
it
should
:
Issue
a
request
with
may
alter
header
field
values
without
sending
unaltered
headers
and
examine
values
in
advance,
providing
that
it
subsequently
assesses
the
response
(see
as
described
under
4.4
Proxy
Response
to
User
Agent
4.2.6
Receipt
of
Vary
HTTP
Header
Field
);
If
it
below,
and
is
still
in
doubt,
issue
a
prepared
to
reissue
the
request
with
altered
headers
unaltered
header
fields,
and
alter
its
subsequent
behavior
in
respect
of
the
Web
site
so
that
unaltered
header
fields
are
sent.
The
A
proxy
must
not
issue
reissue
a
POST/PUT
POST
request
with
altered
headers
header
fields
when
the
response
to
the
unaltered
POST/PUT
POST
request
has
HTTP
status
code
200
(in
other
words,
it
may
only
send
the
altered
request
for
a
POST/PUT
request
when
the
unaltered
one
was
refused
with
a
resulted
in
an
HTTP
406
status).
The
theoretical
idempotency
of
GET
requests
is
response,
and
not
always
respected
a
"request
unacceptable"
response).
Proxies
may
offer
users
an
option
to
choose
to
view
a
restructured
experience
even
when
a
Web
site
offers
a
choice
of
user
experience.
If
a
user
has
made
such
content,
a
choice
then
proxies
should
may
avoid
issuing
duplicate
requests
alter
header
field
values
when
requesting
resources
in
order
to
reflect
that
choice,
but
must
,
on
receipt
of
an
indication
from
a
Web
site
that
it
offers
alternative
representations
(see
H.1.4.2
Indication
of
Intended
Presentation
Media
Type
of
Representation
),
inform
the
user
of
that
and
specifically
allow
them
to
select
an
alternative
representation.
Proxies must assess whether a user's expressed preference for a restructured representation is still valid if a Web site changes its choice of representations (see 4.2.6 Receipt of Vary HTTP Header Field ).
When
requesting
resources
that
are
included
resources
(e.g.
style
sheets,
images),
proxies
should
make
the
request
for
such
resources
with
the
same
User-Agent
header
field
as
the
request
for
the
resource
from
which
they
are
referenced.
For
the
purpose
of
consistency
of
representation,
proxies
may
request
linked
resources
(e.g.
those
referenced
using
the
a
element)
that
form
part
of
the
same
Web
site
as
a
previously
requested
resource
with
the
same
header
fields
as
the
resource
from
which
they
are
referenced.
When
requesting
linked
resources
that
do
not
form
part
of
the
same
Web
site
as
the
resource
from
which
they
are
linked,
proxies
should
not
issue
duplicate
requests
base
their
choice
of
header
fields
on
a
consistency
of
presentation
premise.
Specifically the following mapping must be used:
| Original | Replacement | Ref |
|---|---|---|
User-Agent
|
X-Device-User-Agent
| RFC2616 Section 14.43 |
Accept
|
X-Device-Accept
| RFC2616 Section 14.1 |
Accept-Charset
|
X-Device-Accept-Charset
| RFC2616 Section 14.2 |
Accept-Encoding
|
X-Device-Accept-Encoding
| RFC2616 Section 14.3 |
Accept-Language
|
X-Device-Accept-Language
| RFC2616 Section 14.4 |
The
X-Device-
prefixed
header
names
listed
in
this
section
have
been
provisionally
registered
with
IANA
(see
Provisional
Message
Header
Field
Names
).
Note:
The
X-Device-
prefix
was
chosen
primarily
on
the
basis
that
this
is
an
already
existing
convention.
It
is
noted
that
the
values
encoded
in
such
header
fields
may
not
ultimately
derive
from
a
device,
they
are
merely
received
fields.
The
treatment
of
received
X-Device
header
fields,
which
may
happen
where
there
are
multiple
transforming
proxies,
is
undefined
(see
J
Scope
for
comparison
purposes.
Future
Work
).
Irrespective
of
its
Presence
the
presence
of
a
no-transform
directive:
The
proxy
proxies
must
include
a
Via
HTTP
header
field
(see
4.1.6.1
Proxy
Treatment
of
Via
Header
Field
).
Via
Header
Field
According
to
[RFC
2616
HTTP]
Section
14.45
Via
header
field
comments
"
may
be
removed
by
any
recipient
prior
to
forwarding
the
message".
However,
the
justification
for
removing
such
comments
is
based
on
memory
limitations
of
early
proxies,
and
that
most
proxies.
Most
modern
proxies
do
not
suffer
such
limitations.
If
it
is
capable
of
varying
its
presentation
it
Proxies
should
must
take
account
solicit
re-expression
of
user
agent
capabilities
and
formulate
an
appropriate
experience
according
preferences
in
respect
of
a
server
if
the
server
starts
to
those
criteria.
indicate
that
it
offers
varying
responses
as
discussed
under
4.2.6
Receipt
of
Vary
HTTP
Header
Field
.
Cache-Control:
no-transform
If
the
server
varies
its
presentation
according
to
examination
of
received
HTTP
headers
then
it
must
include
response
includes
a
Vary
Cache-Control:
no-transform
HTTP
header
indicating
this
to
be
the
case.
If,
in
addition
to,
or
instead
of
HTTP
headers,
the
server
varies
its
presentation
on
other
factors
(source
IP
Address
...)
directive
then
it
proxies
must
,
in
accordance
not
alter
it
other
than
to
comply
with
transparent
HTTP
behavior
as
described
in
[RFC
2616
HTTP]
,
include
a
Vary
header
containing
the
value
'*'.
Section
13.5.2
and
Section
14.9.5
and
other
than
as
follows.
If
the
server
has
distinct
presentations
a
proxy
determines
that
vary
according
a
resource
as
currently
represented
is
likely
to
presentation
media,
then
the
medium
for
which
cause
serious
misoperation
of
the
presentation
is
intended
user
agent
then
it
should
may
be
indicated.
Editorial
Note:
The
BPWG
is
studying
the
use
of
advise
the
link
element
of
HTML
which
is
used
for
user
that
this
purpose.
It
is
noted
that
the
link
element
is
not
available
in
formats
other
than
HTML,
case
and
it
is
noted
that
there
is
currently
active
discussion
about
the
use
of
must
provide
the
Link
HTTP
header,
which
would
serve
this
purpose
well.
If
option
for
the
server
creates
a
specific
user
experience
according
to
device
characteristics
or
presentation
media
types
it
continue
with
unaltered
content
(and
should
may
inhibit
transformation
provide
other
options
too).
Vary
HTTP
Header
Field
If
HTTP
header
fields
were
altered
in
the
request
then
the
A
proxy
must
may
not
be
prepared
to
re-issue
the
carrying
out
content
tasting
as
described
under
4.1.5.2
Avoiding
"Request
Unacceptable"
Responses
if
it
anticipates
receiving
a
"request
unacceptable"
response.
However,
if
it
makes
a
request
with
altered
header
fields
in
an
unaltered
form
on
receipt
of
these
circumstances,
and
receives
a
response
containing
a
Vary
header
in
the
response
indicating
that
the
server
offers
variants
of
its
presentation
according
field
referring
to
any
one
of
the
HTTP
altered
header
fields
that
have
been
modified.
Editorial
Note:
The
BPWG
is
aware
that
more
precision
may
be
needed
in
the
above
statement.
If
a
transforming
proxy
has
followed
the
guidelines
in
this
document,
then
it
should
not
receive
a
response
request
the
resource
again
with
a
Vary
unaltered
header
if
fields.
It
should
also
update
whatever
heuristics
it
has
not
already
received
such
a
response
to
a
request
with
uses
so
that
unaltered
headers.
header
fields
are
presented
first
in
subsequent
requests
for
this
resource.
If
the
response
is
an
HTML
response
and
it
contains
a
<link
rel="alternate"
media="handheld"
/>
element,
the
CT-proxy
SHOULD
a
proxy
should
request
and
return
process
the
referenced
resource,
unless
the
resource
referenced
is
the
current
resource
(1k)
representation
.
Note:
In
this
document
the
term
current
representation
means
a
"same
document
reference"
as
determined
by
[unresolved
discussion]
...
.
defined
in
[RFC
3986]
Section
4.4
,
with
the
addition
that
if
a
Vary
HTTP
header
field
was
present
on
the
response
then
it
is
the
same
representation
if
the
values
of
the
HTTP
header
fields
of
the
request
have
not
been
altered.
If the content is WML proxies should act in a transparent manner.
Note:
This does not affect the operation of proxies that are also WAP Gateways.
the
content
to
determine
whether
it
is
appropriate
HTML
and
contains
<link
rel="alternate"
media="handheld"/>
with
a
reference
to
the
restructure
current
representation
;
the
DOCTYPE
of
the
content
(if
it
has
one)
indicates
XHTML-MP,
XHTML
Basic,
WML
or
recode
iMode
as
listed
in
D
DOCTYPEs
Associated
with
Mobile
Content
it
(in
;
the
presence
Content-Type
has
a
value
listed
in
C
Internet
Content
Types
associated
with
Mobile
Content
.
the
URI
of
the
response
(following
redirection
or
as
indicated
by
the
Content-Location
HTTP
header
field)
matches
a
pattern
listed
in
E
URI
Patterns
Associated
with
Mobile
Web
Sites
;
the response contains a resource that is referenced as an included resource suitable for "handheld" in a resource that was itself handled transparently;
a
claim
of
mobileOK
Basic
[mobileOK
Basic
Tests]
conformance
is
indicated
(see
[mobileOK
Scheme]
for
how
such
directives,
heuristics
should
not
a
claim
may
be
used.)
indicated).
Examples
of
heuristics:
Other
factors
that
a
proxy
may
take
into
account:
The
server
Web
site
(see
note
)
has
previously
shown
that
it
is
contextually
aware,
even
if
the
present
response
does
not
indicate
this;
the
Content-Type
or
other
aspects
of
the
response
are
known
to
be
specific
to
the
device
or
class
of
device
(e.g.
for
HTML
documents
the
DOCTYPE
is
"-//OMA//DTD
XHTML
Mobile
1.2//EN",
"-//WAPFORUM//DTD
XHTML
Mobile
1.1//EN"
"-//WAPFORUM//DTD
XHTML
Mobile
1.0//EN"
"-//W3C//DTD
XHTML
Basic
1.1//EN"
and
"-//W3C//DTD
XHTML
Basic
1.0//EN");
the
user
agent
has
features
(such
as
linearization
or
zoom
capabilities
or
other
features
which
zoom)
that
allow
it
to
present
the
content
unaltered;
the
URI
of
the
response
(following
redirection
or
as
indicated
by
the
Content-Location
HTTP
header)
indicates
that
the
resource
is
intended
for
mobile
use
(e.g.
the
domain
is
*.mobi,
wap.*,
m.*,
mobile.*
or
the
leading
portion
of
the
path
is
/m/
or
/mobile/);
the
response
contains
client-side
client
side
scripts
that
may
mis-operate
misoperate
if
the
resource
is
restructured;
the
response
is
an
HTML
response
and
it
includes
<link>
elements
specifying
alternatives
according
to
presentation
media
type.
A
proxy
should
strive
for
the
best
possible
user
experience
that
the
user
agent
supports.
It
should
only
alter
the
format,
layout,
dimensions
etc.
to
match
Other
than
as
noted
in
this
section
the
specific
capabilities
nature
of
the
user
agent.
For
example,
when
resizing
images,
they
should
only
be
reduced
so
restructuring
that
they
are
suitable
for
the
specific
user
agent,
is
carried
out,
any
character
encoding
alterations
and
what
is
omitted
and
what
is
inserted
is,
as
discussed
in
1.3
Scope
,
out
of
scope
of
this
should
not
be
done
on
a
generic
basis.
document.
If
the
a
proxy
alters
the
content
then
it
response
then:
It
must
add
a
Warning
214
Transformation
Applied
HTTP
Header.
header
field;
If
the
proxy
alters
the
content
then
the
The
altered
content
should
validate
according
to
an
appropriate
published
formal
grammar.
grammar
and
if
XML
must
be
well-formed
;
If
It
should
indicate
to
the
response
contains
links
whose
user
that
the
content
has
been
transformed
for
mobile
presentation
and
provide
an
option
to
view
the
original,
unmodified
content.
In
this
document
two
URIs
have
the
scheme
Same-Origin
if
the
component
and
the
https
scheme
host
and
port
subcomponents,
as
defined
in
[RFC
3986]
,
all
match.
Section
6
of
[RFC
3986]
discusses
URI
comparison.
Some proxy deployments have to "rewrite" links in content in order for the User Agent to request the referenced resources through the proxy. In so doing, proxies make unrelated resources appear as though they have the same-origin and hence there is a danger of introducing security vulnerabilities.
Note:
This section (on link rewriting) refers also to insertion of links, frame flattening and any other techniques that introduces the "same-origin" issue.
Note:
Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile adapted web search and navigation to the web pages returned in the search results, or to which the browser is redirected through the CT Proxy for adaptation of a web page. Link rewriting may be used by CT Proxies acting as normal HTTP proxies (e.g. configured or transparent) for the browser, but may not be required since all browser requests flow through the CT Proxy.
Proxies
must
not
only
rewrite
them
so
links
when
content
transformation
is
prohibited.
Proxies must preserve security between requests for domains that are not same-origin in respect of cookies and scripts.
The practice of intercepting HTTPS links is strongly NOT RECOMMENDED .
If
Notwithstanding
anything
else
in
this
document,
proxies
must
not
rewrite
HTTPS
links
in
the
response
includes
presence
of
a
Cache-Control:
no-transform
directive
then
the
response
must
remain
unaltered
other
than
to
comply
with
transparent
directive.
HTTP
behavior
and
other
than
as
noted
below.
When
forwarding
requests
originating
from
HTTPS
links
proxies
must
include
a
Via
header
field
as
currently
represented
is
likely
to
cause
serious
mis-operation
discussed
under
4.1.6.1
Proxy
Treatment
of
the
user
agent
then
it
Via
Header
Field
.
When
forwarding
responses
from
servers
proxies
may
,
with
the
users
explicit
prior
consent,
warn
must
notify
the
user
and
provide
links
to
both
transformed
and
unaltered
versions
of
the
resource.
invalid
server
certificates.
Editorial Note: Update to final location
See http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/ics-090923
Using the notation defined in [POWDER Resource Grouping]:
<iriset> <includehosts>mobi</includehosts> </iriset>
User preferences are also referred to non-normatively under H.1.4 Varying Representations .
Request resource with original header fields
If the response is a 406 response:
If
the
response
contains
Cache-Control:
no-transform
,
forward
it
Otherwise request again with altered header fields
If the response is a 200 response:
Otherwise assess whether the 200 response is a form of "Request Unacceptable"
Proxy receives a request for resource P that it has not encountered before
Response is a desktop oriented representation of the resource
Proxy transforms this response into content that the user agent can display well and forwards it
Proxy receives a further request for the resource P
Response is a desktop oriented representation of the resource
Proxy transforms this response into content that the user agent can display well and forwards it
Proxy receives a request for resource P, that it has previously encountered as in G.2 Optimization based on Previous Server Interaction
Proxy forwards request with altered header fields
Response
is
200
OK
containing
a
Vary:
User-Agent
header
field
Proxy notices that behavior has changed and reissues the request with original header fields
Response is 200 OK and proxy forwards it
Content providers may wish to follow these procedures in order to improve interoperability.
Vary
HTTP
Header
Field
If
a
server
varies
its
representation
according
to
examination
of
received
HTTP
header
fields
then
[RFC
2616
HTTP]
describes
how
to
use
the
Vary
header
field
to
indicate
this.
Servers
that
are
aware
of
the
presence
of
a
transforming
proxy,
as
identified
by
a
Via
HTTP
Header
field
might
alter
their
responses
according
to
their
knowledge
of
specific
proxy
behavior.
When
doing
so
it
is
good
practice
to
make
sure
that
the
Internet
content
type
for
a
response
is
correct
for
the
actual
content
(e.g.
a
server
should
not
choose
Content-Type:
application/vnd.wap.xhtml+xml
because
it
suspects
that
proxies
will
not
transform
content
of
this
type,
if
its
content
is
not
valid
XHTML-MP).
If
a
server
has
distinct
representations
that
vary
according
to
the
target
presentation
media
type,
it
can
inhibit
transformation
of
the
response
by
including
a
Cache-Control:
no-transform
directive
(see
H.1.3
Server
Origination
of
Cache-Control:
no-transform
).
In
addition,
in
HTML
content
it
can
indicate
the
medium
for
which
the
representation
is
intended
by
including
a
link
element
identifying
in
its
media
attribute
the
target
presentation
media
types
of
this
representation
and
setting
the
href
attribute
to
"Same-Document
Reference"
(see
[RFC
3986]
section
4.4
)
and
in
particular
an
empty
href
attribute
is
a
"Same
Document
Reference".
In
addition
it
is
good
practice
to
include
link
elements
identifying
the
target
presentation
media
types
of
other
available
representations
in
a
similar
manner.
If
content
for
more
than
one
presentation
media
type
is
served
from
the
same
URI,
it
is
better
not
to
use
a
link
element
identifying
the
presentation
media
types
as
the
URI
will
appear
to
be
a
"same
document
reference",
indicating
to
a
client
that
this
representation
is
suitable
for
all
the
named
presentation
media
types.
Instead,
use
a
Vary
HTTP
header
field
indicating
that
the
response
varies
according
to
the
received
User-Agent
HTTP
header
field.
Note:
Some
examples
of
the
use
of
the
link
element
are
included
above
in
G
Example
Transformation
Interactions
.
The
BPWG
believes
that
POWDER
[POWDER]
POWDER
will
represent
a
powerful
mechanism
by
which
a
server
may
express
transformation
preferences.
Future
work
in
this
area
may
recommend
the
use
of
POWDER.
POWDER
to
provide
a
mechanism
for
origin
servers
to
indicate
more
precisely
which
alternatives
they
have
and
what
transformation
they
are
willing
to
allow
on
them,
and
in
addition
to
provide
for
Content
Transformation
proxies
to
indicate
which
services
they
are
able
to
perform.
At present HTTP does not provide a mechanism for communicating original header field values. The scheme based on X-Device prefixed fields described under 4.1.5 Alteration of HTTP Header Field Values records and clarifies an approach used to achieve this effect by some content transformation proxies. This scheme relies upon non-standard HTTP fields, which are identified by their prefix as experimental according to IETF standards (notably RFC 822 and RFC 2076), and are not included in the IANA registry of HTTP header fields. While the mechanism defined in that section, based on current practice, applies to conforming transformation proxy deployments, it is possible that in future, in collaboration with the IETF, this approach will be reconsidered. This implies that the specified X-Device prefixed fields may, at some time, become deprecated in favor of new equivalent fields, or that an entirely different approach will be taken to representing such values.
A
number
of
mechanisms
exist
in
HTTP
which
might
be
exploited
given
more
precise
definition
of
their
operation
-
for
example
the
OPTIONS
method
and
the
HTTP
300
(Multiple
Choices)
Status.
The
editors
acknowledge
editor
acknowledges
contributions
of
various
kinds
from
members
of
the
MWI
BPWG
Mobile
Web
Best
Practices
Working
Group
and
earlier
from
the
Content
Transformation
Task
Force
.
of
that
group.
The editor acknowledges significant written contributions from: