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/ .
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
3
Conformance
(Normative)
3.1
Classes
of
Product
3.2
Normative
and
Informative
Parts
3.3
Normative
Language
for
Conformance
Requirements
3.4
Content
Deployment
Conformance
3.5
Transformation
Deployment
Conformance
4
Behavior
of
Components
(Normative)
4.1
Proxy
Forwarding
of
Request
4.1.1
Applicable
HTTP
Methods
4.1.2
no-transform
directive
in
Request
4.1.3
Treatment
of
Requesters
that
are
not
Web
browsers
4.1.4
Serving
Cached
Responses
4.1.5
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.2.1
Use
of
HTTP
406
Status
4.2.2
Server
Origination
of
Cache-Control:
no-transform
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)
D.1
POWDER
D.2
link
HTTP
Header
D.3
Sources
of
Device
Information
D.4
Inter
Proxy
Communication
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 BPWG is not chartered to create new 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 :
"A
transparent
proxy
is
a
proxy
that
does
not
modify
the
request
or
response
beyond
what
is
required
for
proxy
authentication
and
identification.
.
A
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.
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 proxies, when used for Content Transformation in the context discussed in [CT Landscape] .
There are three classes of operation on responses:
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 handling this response.
Recoding content
Optimizing content
The Content Transformation Guidelines specification has two classes of products:
A Transformation Deployment is the provision of non-transparent components in the path of HTTP requests and responses. Provisions that are applicable to a Transformation Deployment are identified in this document by use of the term "transforming proxy" or "proxy" in the singular or plural.
The key words must , must not , required , shall , shall not , should , should not , recommended , may , and optional in this Recommendation have the meaning defined in [RFC 2119] .
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
proxies
must
forward
the
request
unaltered
to
the
server,
other
than
to
comply
with
transparent
HTTP
behavior
and
as
noted
below
(see
4.1.6
Additional
HTTP
Headers
).
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.
Proxies
must
act
as
though
a
no-transform
directive
is
present
(see
4.1.2
no-transform
directive
in
Request
)
unless
they
are
able
positively
to
determine
that
the
user
agent
is
a
Web
browser.
The
mechanism
by
which
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.
Other than to comply with transparent HTTP operation, proxies should not modify request headers unless:
the user would be prohibited from accessing content as a result of the server responding that the request is "unacceptable" (see 4.3.3 Server Rejection of HTTP Request );
the user has specifically requested a restructured desktop experience;
the request is part of a 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:
In this section, the concept of "Web site" is used (rather than "origin server") as some origin servers host many different Web sites. Since the concept of "Web site" is not strictly defined, proxies should use heuristics including comparisons of domain name to assess whether resources form part of the same "Web site".
A proxy may reissue a request with altered HTTP header values if a previous request with unaltered values resulted in the origin server rejecting the request as "unacceptable" (see 4.3.3 Server Rejection of HTTP Request ). A proxy may apply heuristics of various kinds to assess, in advance of sending unaltered header values, whether the request is likely to cause a "request unacceptable" response. If it determines that this is likely then it may alter header values without sending unaltered values in advance, providing that it subsequently assesses the response as described under 4.3.4 Receipt of Vary HTTP Header below, and is prepared to reissue the request with unaltered headers, and alter its subsequent behavior in respect of the Web site so that unaltered headers are sent.
A proxy must not 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 resulted in an HTTP 406 response, and not 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 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 default users will wish to 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 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
Future
Work
).
Irrespective
of
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,
most
modern
proxies
do
not
suffer
such
limitations.
Cache-Control:
no-transform
Servers
must
include
a
Cache-Control:
no-transform
directive
if
one
is
received
in
the
HTTP
request.
Vary
HTTP
Header
If
a
server
varies
its
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,
a
server
varies
its
representation
based
on
other
factors
(e.g.
source
IP
Address)
then
it
must
,
in
accordance
with
[RFC
2616
HTTP]
,
include
a
Vary
header
containing
the
value
'*'.
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
representations
that
vary
according
to
the
target
presentation
media
type,
it
should
inhibit
transformation
of
the
response
by
including
a
Cache-Control:
no-transform
directive
(see
4.2.2
Server
Origination
of
Cache-Control:
no-transform
).
In
HTML
content
it
should
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
by
setting
the
media
attribute
and
set
setting
the
href
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);
document).
In
addition
it
should
include
link
elements
identifying
the
target
presentation
media
types
of
other
available
representations
by
setting
the
media
attribute
to
indicate
those
representations
and
set
the
href
attribute
to
a
URI
without
a
fragment
identifier.
Note:
The
presence
of
the
link
elements
which
do
not
contain
a
valid
local
reference
does
not
indicate
one
way
or
another
whether
this
representation
is
formatted
for
the
presentation
media
types
listed.
Note:
Some
examples
of
the
use
of
the
link
element
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
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 user agent then it may advise the user that this is the case and must provide the option for the user to continue with unaltered content.
For compatibility with servers that do not implement this Recommendation (see 4.2.1 Use of HTTP 406 Status ), a proxy may treat responses with an HTTP 200 Status as though they were responses with an HTTP 406 Status if it has determined that the content (e.g. "Your browser is not supported") is equivalent to a response with an HTTP 406 Status.
Vary
HTTP
Header
If,
in
response
to
an
HTTP
request
with
altered
headers
that
was
not
preceded
by
an
HTTP
request
with
unaltered
headers,
a
proxy
receives
a
response
containing
a
Vary
header
referring
to
one
of
the
altered
headers
then
it
should
request
the
resource
again
and
with
unaltered
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
request
and
process
the
referenced
resource,
unless
the
resource
referenced
is
the
current
resource
as
determined
by
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
)
proxies
should
apply
heuristics
to
the
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 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;
Examples of mobile specific DOCTYPEs:
-//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
-//W3C//DTD XHTML Basic 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.
Request resource with original headers
If the response is a 406 response:
If
the
response
contains
Cache-Control:
no-transform
,
forward
it
Re-request
Otherwise
re-request
with
altered
headers
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 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 will represent a powerful mechanism by which a server may express transformation preferences. Future work in this area may recommend the use of 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
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.
It is noted that there are means which fall outside of the scope of this document for establishing user preferences with content transformation proxies. It is anticipated that proxies will maintain preferences on a user by user and 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 editor acknowledges contributions of various kinds from members of the Mobile Web Best Practices Working Group Content Transformation Task Force .
The editor acknowledges significant written contributions from: