Copyright © 2008 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/
.
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
Summary
of
Requirements
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
Normative
and
Informative
Parts
3.2.2
Control
by
Server
3.3
Normative
Language
for
Conformance
Requirements
3.2.3
Control
by
Administrative
or
Other
Arrangements.
3.4
Content
Deployment
Conformance
3.2.4
Resolving
Conflicting
Instructions
3.5
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
Values
4.1.5.1
Content
Tasting
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
Headers
4.1.6
Additional
HTTP
Headers
4.1.6.1
Proxy
Treatment
of
Via
Header
4.2
Server
Response
to
Proxy
4.3
Proxy
Receipt
and
Forwarding
4.2.1
Use
of
Response
from
HTTP
406
Status
4.2.2
Server
Origination
of
Cache-Control:
no-transform
4.4
4.2.3
Varying
Representations
4.2.3.1
Use
of
Vary
HTTP
Header
4.2.3.2
Indication
of
Intended
Presentation
Media
Type
of
Representation
4.3
Proxy
Forwarding
of
Response
to
User
Agent
4.3.1
Receipt
of
Cache-Control:
no-transform
4.3.2
Receipt
of
Warning:
214
Transformation
Applied
4.3.3
Server
Rejection
of
HTTP
Request
4.3.4
Receipt
of
Vary
HTTP
Header
4.3.5
Link
to
"handheld"
Representation
4.3.6
Proxy
Decision
to
Transform
4.3.6.1
Alteration
of
Response
4.3.6.2
HTTPS
Link
Re-writing
5
Testing
(Normative)
A
References
B
Example
Transformation
Interactions
(Non-Normative)
B.1
Basic
Content
Tasting
by
Proxy
B.2
Optimization
based
on
Previous
Server
Interaction
B.3
Optimization
based
on
Previous
Server
Interaction,
Server
has
Changed
its
Operation
B.4
Server
Response
Indicating
that
this
Representation
is
Intended
for
the
Target
Device
B.5
Server
Response
Indicating
that
another
Representation
is
Intended
for
the
Target
Device
C
Applicability
to
Transforming
Solutions
which
are
Out
of
Scope
(Non-Normative)
D
Scope
for
Future
Work
(Non-Normative)
B.1
D.1
POWDER
B.2
D.2
link
HTTP
Header
B.3
Amendments
to
HTTP
D.3
Sources
of
Device
Information
B.4
D.4
Inter
Proxy
Communication
C
Acknowledgments
D.5
Amendment
to
and
Refinement
of
HTTP
E
Administrative
Arrangements
(Non-Normative)
F
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
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,
directives
and
behaviors
must
be
respected,
and
as
far
as
is
practical,
no
extensions
to
[RFC
2616
HTTP]
are
to
be
used.
The needs of these actors are as follows:
The user agent needs to be able to tell the Content Transformation proxy and the origin server:
The Content Transformation proxy needs to be able to tell the origin server:
that some degree of Content Transformation ( restructuring and recoding ) can be performed;
that content is being requested on behalf of something else and what that something else is;
that the request headers have been altered and what the original ones were.
The origin server needs to be able to tell the Content Transformation proxy:
that it varies the representation of its responses according to device type and other factors;
that it is not permissible to perform Content Transformation;
that it has media-specific representations;
that is unable or unwilling to deal with the request in its present form.
The Content Transformation proxy needs to be able to tell the user agent:
that it has applied transformations of various kinds to the content.
The Content Transformation proxy needs to be able to interact with the user:
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 of the content.
Note:
A more extensive discussion of the requirements for these guidelines can be found in "Content Transformation Landscape" [CT Landscape] .
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 .
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
or
pagination.
It
includes
also
rewriting
of
URIs
so
that
subsequent
requests
route
via
the
proxy.]
proxy
handling
this
response.
Recoding content
Optimizing content
The
Content
A
Transformation
proxy
needs
to
be
able
to
tell
Deployment
is
the
origin
server:
that
some
degree
provision
of
Content
Transformation
(
restructuring
and
recoding
non-transparent
)
can
be
performed;
that
Content
Transformation
will
be
carried
out
unless
requested
not
to;
that
content
is
being
requested
on
behalf
of
something
else
and
what
that
something
else
is;
that
the
request
headers
have
been
altered
(e.g.
additional
content
types
inserted).
The
origin
server
needs
to
be
able
to
tell
components
in
the
Content
Transformation
proxy:
that
it
varies
its
presentation
according
to
device
type
path
of
HTTP
requests
and
other
factors;
responses.
Provisions
that
it
is
permissible
(or
not)
are
applicable
to
perform
Content
a
Transformation
of
various
kinds;
that
it
has
media-specific
representations;
that
is
unable
or
unwilling
to
deal
with
the
request
Deployment
are
identified
in
its
present
form.
The
Content
Transformation
proxy
needs
to
be
able
to
tell
the
user
agent:
that
it
has
applied
transformations
this
document
by
use
of
various
kinds
to
the
content.
The
Content
Transformation
proxy
needs
to
be
able
to
interact
with
the
user:
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
of
term
"transforming
proxy"
or
"proxy"
in
the
content.
singular
or
plural.
A
transforming
proxy
as
described
in
Normative
parts
of
this
document
must
offer
a
level
are
identified
by
the
use
of
control
to
users
and
to
origin
servers
with
which
it
communicates.
3.2.1
Control
"(Normative)"
following
the
section
name.
Informative
parts
are
identified
by
use
of
"(Non-Normative)"
following
the
User
section
name.
They
The
key
words
must
,
must
not
,
required
,
shall
,
shall
not
,
should
,
should
not
,
recommended
,
may
also
provide
the
ability
for
their
users
to
make
a
persistent
or
semi-persistent
expression
of
preferences.
Examples
of
such
settings
are
"Never
transform",
"Always
request
desktop
presentation",
"Transform
only
if
necessary
to
avoid
mis-operation"
,
and
"Compress
where
possible".
Editorial
Note:
The
BPWG
is
studying
how
to
clarify
optional
in
this
Recommendation
have
the
scope
of
"persistent"
and
"semi-persistent".
meaning
defined
in
[RFC
2119]
.
Transforming
proxies
must
allow
origin
servers
A
Content
Deployment
conforms
to
control
these
guidelines
if
it
follows
the
Content
Transformation
process.
The
control
mechanisms
include
use
of
HTTP
conventions
as
discussed
statements
in
the
following
section
(
4
Behavior
of
Components
4.2
Server
Response
to
Proxy
).
.
the
use
by
transforming
proxies
of
a
disallow
list
of
Web
sites
for
which
Content
A
Transformation
is
known
Deployment
conforms
to
diminish
these
guidelines
if
it
follows
the
user
experience
of
content
or
be
ineffective;
statements
in
the
use
by
transforming
proxies
of
an
allow
list
4.1
Proxy
Forwarding
of
Web
sites
for
which
Content
Transformation
is
known
to
be
necessary;
Request
,
terms
and
conditions
4.3
Proxy
Forwarding
of
service,
as
agreed
between
the
user
and
the
Content
Transformation
service
provider.
Note:
Allow
and
disallow
lists
generally
cause
intractable
problems
for
content
providers
since
there
is
no
mechanism
for
them
Response
to
establish
which
lists
they
should
be
on,
nor
any
generic
mechanism
though
which
they
can
check
or
change
their
status.
User
Agent
3.2.4
Resolving
Conflicting
Instructions
There
is
the
possibility
for
conflict
between
the
desires
of
the
content
provider
and
the
desires
of
users
of
that
content.
This
document
sets
out
to
provide
a
framework
within
which,
for
matters
of
presentation,
the
desires
of
the
content
provider
are
usually
accommodated
but,
where
necessary,
the
user
may
expressly
override
those
desires
with
their
preferences.
5
Testing
(Normative)
.
Proxies should not intervene in methods other than GET, POST, HEAD and PUT.
If the HTTP method is altered from HEAD to GET, proxies should (providing such action is in accordance with normal HTTP caching rules) cache the response so that a second GET request for the same content is not required (see also 4.1.4 Serving Cached Responses ).
no-transform
directive
in
Request
If
the
request
contains
a
Cache-Control:
no-transform
directive
the
proxy
proxies
must
forward
the
request
unaltered
to
the
server,
other
than
to
comply
with
transparent
HTTP
behavior
and
in
particular
to
add
a
Via
as
noted
below
(see
4.1.6
Additional
HTTP
header.
Headers
).
Note:
An
example
of
the
use
of
Cache-Control:
no-transform
is
the
issuing
of
asynchronous
HTTP
requests,
perhaps
by
means
of
XMLHttpRequest
XMLHTTPRequest
[XHR]
,
which
may
include
such
a
directive
in
order
to
prevent
transformation
of
both
the
request
and
the
response.
the
proxy
Proxies
should
must
add
the
IP
address
of
the
initiator
of
the
request
to
the
end
of
act
as
though
a
comma
separated
list
in
an
X-Forwarded-For
no-transform
HTTP
header;
directive
is
present
(see
the
proxy
must
behave
transparently
4.1.2
no-transform
directive
in
Request
)
unless
it
is
they
are
able
positively
to
determine
that
the
user
agent
is
a
Web
browser.
The
mechanism
by
which
the
a
proxy
recognizes
the
user
agent
as
a
Web
browser
should
use
evidence
from
the
HTTP
request,
in
particular
the
User-Agent
and
Accept
headers.
If
there
is
no
no-transform
directive
present
Proxies
should
follow
standard
HTTP
procedures
in
the
request
the
proxy
respect
of
caching
and
should
analyze
whether
it
intends
to
offer
transformation
services
by
referring
to:
any
knowledge
it
has
use
cached
copies
of
user
preferences;
resources
where
this
is
in
accordance
with
those
procedures.
any
knowledge
it
has
of
user
agent
capabilities
(including
linearization
In
some
circumstances,
proxies
may
paginate
responses
and
zoom);
any
prior
knowledge
it
has
of
server
behavior,
derived
from
previous
interaction
with
where
this
is
the
server
-
and
in
particular
to
preserve
case
a
request
may
be
for
a
subsequent
page
of
a
previously
requested
resource.
In
this
case
proxies
may
for
the
sake
of
consistency
of
representation
serve
stale
data
but
when
doing
so
should
notify
the
user
experience
across
that
this
is
the
case
and
should
provide
a
sequence
simple
means
of
related
requests;
retrieving
a
fresh
copy.
Proxies
Other
than
to
comply
with
transparent
HTTP
operation,
proxies
should
not
alter
HTTP
requests
modify
request
headers
unless:
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.3.3
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;
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".
A
transforming
proxy
may
convert
reissue
a
HEAD
request
into
with
altered
HTTP
header
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.3.3
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
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
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.3.4
Receipt
of
Vary
HTTP
Header
);
If
it
below,
and
is
still
in
doubt,
issue
a
prepared
to
reissue
the
request
with
altered
unaltered
headers,
and
alter
its
subsequent
behavior
in
respect
of
the
Web
site
so
that
unaltered
headers
are
sent.
The
A
proxy
must
not
issue
re-issue
a
POST/PUT
request
with
altered
headers
when
the
response
to
the
unaltered
POST/PUT
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).
response,
and
not
a
"request
unacceptable"
response).
The
theoretical
idempotency
Proxies
may
offer
users
an
option
to
choose
to
view
a
restructured
experience
even
when
a
Web
site
offers
a
choice
of
GET
requests
is
not
always
respected
user
experience.
If
a
user
has
made
such
a
choice
then
proxies
may
alter
header
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
4.2.3.2
Indication
of
Intended
Presentation
Media
Type
of
Representation
),
inform
the
user
of
that
and
allow
them
to
select
an
alternative
representation.
Proxies
should
assume
that
by
servers.
In
order,
as
far
as
possible,
default
users
will
wish
to
avoid
mis-operation
receive
a
representation
prepared
by
the
Web
site.
Proxies
must
assess
whether
a
user's
expressed
preference
for
a
restructured
representation
is
still
valid
if
a
Web
site
changes
its
choice
of
such
content,
representations
(see
4.3.4
Receipt
of
Vary
HTTP
Header
).
The
X-Device-
prefix
was
chosen
primarily
on
the
basis
that
this
is
a
already
existing
convention.
It
is
noted
that
the
values
encoded
in
such
header
may
not
ultimately
derive
from
a
device,
they
are
merely
received
headers.
The
treatment
of
received
X-Device
headers,
which
may
happen
where
there
are
multiple
transforming
proxies,
is
undefined
(see
D
Scope
for
comparison
purposes.
Future
Work
).
Irrespective
of
its
Presence
the
presence
of
a
no-transform
directive:
Via
Header
When
forwarding
Via
headers
proxies
should
not
alter
them
in
any
way.
According
to
[RFC
2616
HTTP]
Section
14.45
Via
header
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
modern
proxies
do
not
suffer
such
limitations.
Vary
HTTP
Header
If
the
a
server
varies
its
presentation
representation
according
to
examination
of
received
HTTP
headers
then
it
must
include
a
Vary
HTTP
header
indicating
this
to
be
the
case.
If,
in
addition
to,
or
instead
of
HTTP
headers,
the
a
server
varies
its
presentation
representation
based
on
other
factors
(source
(e.g.
source
IP
Address
...)
Address)
then
it
must
,
in
accordance
with
[RFC
2616
HTTP]
,
include
a
Vary
header
containing
the
value
'*'.
If
Servers
may
base
their
actions
on
knowledge
of
behavior
of
specific
transforming
proxies,
as
identified
in
a
Via
header,
but
should
not
choose
an
Internet
content
type
for
a
response
based
on
an
assumption
or
heuristics
about
behavior
of
any
intermediaries.
(e.g.
a
server
should
not
choose
Content-Type:
application/vnd.wap.xhtml+xml
solely
on
the
basis
that
it
suspects
that
proxies
will
not
transform
content
of
this
type).
If
a
server
has
distinct
presentations
representations
that
vary
according
to
presentation
media,
then
the
medium
for
which
the
target
presentation
is
intended
media
type,
it
should
be
indicated.
Editorial
Note:
The
BPWG
is
studying
the
use
inhibit
transformation
of
the
response
by
including
a
link
Cache-Control:
no-transform
element
directive
(see
4.2.2
Server
Origination
of
Cache-Control:
no-transform
).
In
HTML
which
is
used
content
it
should
indicate
the
medium
for
this
purpose.
It
is
noted
that
which
the
representation
is
intended
by
including
a
link
element
is
not
available
identifying
in
formats
other
than
HTML,
and
it
is
noted
that
there
is
currently
active
discussion
about
the
use
of
the
its
Link
media
HTTP
header,
which
would
serve
this
purpose
well.
If
attribute
the
server
creates
a
specific
user
experience
according
to
device
characteristics
or
target
presentation
media
types
it
should
inhibit
transformation
of
this
representation
and
setting
the
response
by
including
a
Cache-Control:
no-transform
href
directive.
attribute
to
a
valid
local
reference
(i.e.
use
the
fragment
identifier
(see
[RFC
3986]
section
3.5
)
added
to
the
URI
of
the
document
being
served
to
point
to
a
valid
target
within
the
document).
The
server
In
addition
it
must
should
include
a
Cache-Control:
no-transform
link
directive
if
one
is
received
from
elements
identifying
the
user
agent.
target
presentation
media
types
of
other
available
representations
by
setting
the
media
attribute
to
indicate
those
representations
and
the
href
attribute
to
a
URI
without
a
fragment
identifier.
Note:
Including
a
The
presence
of
Cache-Control:
no-transform
link
directive
can
disrupt
elements
which
do
not
contain
a
valid
local
reference
does
not
indicate
one
way
or
another
whether
this
representation
is
formatted
for
the
behavior
of
WAP/WML
proxies,
because
it
can
inhibit
such
proxies
from
converting
WML
to
WMLC.
presentation
media
types
listed.
Note:
If
Some
examples
of
the
use
of
the
server
is
unable
to
add
a
Cache-Control
HTTP
headers,
it
may
,
in
HTML
documents,
add
a
element
meta
HTTP-Equiv
link
containing
Cache-Control:
no-transform
.
are
included
below
in
B
Example
Transformation
Interactions
.
Cache-Control:
no-transform
If
the
response
includes
a
Cache-Control:
no-transform
directive
then
proxies
must
not
alter
it
other
than
to
comply
with
transparent
HTTP
header
fields
were
altered
in
behavior
and
other
than
as
follows.
If
a
proxy
determines
that
a
resource
as
currently
represented
is
likely
to
cause
serious
mis-operation
of
the
request
user
agent
then
it
may
advise
the
proxy
user
that
this
is
the
case
and
must
be
prepared
to
re-issue
provide
the
request
in
an
option
for
the
user
to
continue
with
unaltered
form
on
receipt
content.
For
compatibility
with
servers
that
more
precision
may
be
needed
in
the
above
statement.
If
do
not
implement
this
Recommendation
(see
4.2.1
Use
of
HTTP
406
Status
),
a
transforming
proxy
may
treat
responses
with
an
HTTP
200
Status
as
though
they
were
responses
with
an
HTTP
406
Status
if
it
has
followed
determined
that
the
guidelines
in
this
document,
then
it
should
content
(e.g.
"Your
browser
is
not
receive
supported")
is
equivalent
to
a
response
with
a
an
HTTP
406
Status.
Vary
header
if
it
has
HTTP
Header
If,
in
response
to
an
HTTP
request
with
altered
headers
that
was
not
already
received
such
preceded
by
an
HTTP
request
with
unaltered
headers,
a
proxy
receives
a
response
to
containing
a
Vary
header
referring
to
one
of
the
altered
headers
then
it
should
request
the
resource
again
with
unaltered
headers.
headers,
it
should
update
whatever
heuristics
it
uses
so
that
unaltered
headers
are
presented
first
in
subsequent
requests
for
this
resource
and
it
should
resume
the
behavior
described
under
4.1.5.2
Avoiding
"Request
Unacceptable"
Responses
to
avoid
rejection
of
subsequent
requests.
If
the
response
is
an
HTML
response
and
it
contains
a
<link
rel="alternate"
media="handheld"
/>
element,
the
CT-proxy
SHOULD
should
request
and
return
process
the
referenced
resource,
unless
the
resource
referenced
is
the
current
resource
(1k)
as
determined
by
[unresolved
discussion]
...
.
the
presence
of
link
elements
as
discussed
under
4.2.3.2
Indication
of
Intended
Presentation
Media
Type
of
Representation
.
In
the
absence
of
a
Vary
or
no-transform
directive
(or
a
meta
HTTP-Equiv
element
containing
Cache-Control:
no-transform
)
the
proxy
proxies
should
apply
heuristics
to
the
content
response
to
determine
whether
it
is
appropriate
to
restructure
or
recode
it
(in
the
presence
of
such
directives,
heuristics
should
not
be
used.)
Examples of heuristics:
The
server
Web
site
(see
note
)
has
previously
shown
that
it
is
contextually
aware,
even
if
the
present
response
does
not
indicate
this;
a claim of mobileOK Basic [mobileOK Basic Tests] conformance is indicated;
the
Content-Type
or
other
aspects
of
the
response
(such
as
the
DOCTYPE)
are
known
to
be
specific
to
the
device
or
class
of
device
(e.g.
for
HTML
documents
the
DOCTYPE
is
"-//OMA//DTD
device;
Examples of mobile specific DOCTYPEs:
-//OMA//DTD XHTML Mobile1.2//EN", "-//WAPFORUM//DTD1.2//EN
-//WAPFORUM//DTD XHTML Mobile1.1//EN" "-//WAPFORUM//DTD1.1//EN
-//WAPFORUM//DTD XHTML Mobile1.0//EN" "-//W3C//DTD1.0//EN
-//W3C//DTD XHTML Basic1.1//EN" and "-//W3C//DTD1.1//EN
-//W3C//DTD XHTML Basic1.0//EN");1.0//EN)
the user agent has linearization or zoom capabilities or other features which 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 scripts that may mis-operate if the resource is restructured;
the
response
is
an
HTML
response
and
it
includes
<link>
elements
specifying
alternatives
according
to
presentation
media
type.
If
the
a
proxy
alters
the
content
then
it
response
then:
It
must
add
a
Warning
214
Transformation
Applied
HTTP
Header.
header;
If
the
proxy
alters
the
content
then
the
The
altered
content
should
validate
according
to
an
appropriate
published
formal
grammar.
grammar;
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 B.2 Optimization based on Previous Server Interaction
Proxy forwards request with altered headers
Response
is
200
OK
containing
a
Vary:
User-Agent
header
Proxy notices that behavior has changed and re-issues request with original headers
Response is 200 OK and proxy forwards it
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
recoding
altered
communicating
original
header
values.
values
(hence
the
use
of
X-Device-
headers
as
discussed
under
4.1.5
Alteration
of
HTTP
Header
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.
There
It
is
noted
that
there
are
means
which
fall
outside
of
the
scope
for
further
work
to
define
how
multiple
proxies
may
inter-operate.
A
common
case
of
multiple
proxies
this
document
for
establishing
user
preferences
with
content
transformation
proxies.
It
is
where
anticipated
that
proxies
will
maintain
preferences
on
a
network
provider
transforming
proxy
user
by
user
and
a
search
engine
transforming
proxy
are
both
present.
Web
site
by
Web
site
basis,
and
will
change
their
behavior
in
the
light
of
changing
circumstances
as
discussed
under
4.3.4
Receipt
of
Vary
HTTP
Header
.
The
editors
acknowledge
editor
acknowledges
contributions
of
various
kinds
from
members
of
the
MWI
BPWG
Mobile
Web
Best
Practices
Working
Group
Content
Transformation
Task
Force
.
The editor acknowledges significant written contributions from: