Copyright
© 2008 © 2009 W3C ® (
MIT ,
ERCIM
, Keio ), All Rights Reserved.
W3C liability
, trademark
and document
use rules apply.
This document provides guidance to content
transformation Content
Transformation proxies and content
providers as to whether and how
inter-work when delivering to transform Web content.
Content Transformation proxies alter requests sent by user agents to servers and responses returned by servers so that the appearance, structure or control flow of Web applications are modified. Content Transformation proxies are mostly used to convert Web sites designed for desktop computers to a form suitable for mobile devices.
Based on current practice and standards, this document specifies mechanisms with which Content Transformation proxies should make their presence known to other parties, present the outcome of alterations performed on HTTP traffic, and react to indications set by clients or servers to constrain these alterations.
The objective is to reduce undesirable effects on Web applications, especially mobile-ready ones, and to limit the diversity in the modes of operation of Content Transformation proxies, while at the same time allowing proxies to alter content that would otherwise not display successfully on mobile devices.
Important considerations regarding the impact on security are highlighted.
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)
From the point of view of
Within this document, document
Content Transformation is
refers to the manipulation in various ways, by proxies, of requests
made to to,
and content delivered by responses from, an origin server with a view server.
This manipulation is carried out by proxies in order to
provide a better user experience of content
that would otherwise result in an unsatisfactory experience on the
device making it more suitable for
mobile presentation. the
request.
The W3C MWI BPWG Mobile Web Best Practices Working Group neither
approves nor disapproves of Content Transformation, but recognizes
that is being deployed widely across mobile data access networks.
The deployments are widely divergent to each other, with many
non-standard HTTP implications, and no well-understood means either
of identifying the presence of such transforming proxies, nor of
controlling their actions. This document establishes a framework to
allow that to happen.
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 audience for this document is creators of Content
Transformation proxies, proxies and purchasers and operators of such
proxies and proxies. The document also contains non-normative
guidance for content providers whose services may be accessed
by means of such proxies.
The recommendations in this document refer only to "Web
browsing" - i.e. access by user agents that are intended primarily
for interaction by users with HTML Web pages (Web browsers). Note: The document is not intended as
guidelines for delivery browsers) using
HTTP. Clients that interact with proxies using mechanisms other
than HTTP (and that typically involve the download of
WAP/WML. Some a
special client) are out of its
recommendations may, scope, and are
considered to be a distributed user agent. Proxies which are
operated in some circumstances ,
disrupt the delivery control of WML.
or under the direction of the operator of an
origin server are similarly considered to be a distributed origin
server and hence out of scope.
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.
The Web allows users considerable flexibility in respect of the representation of content. At the same time, Content Providers may have a preferred manner in which they wish their content to be represented. Content Transformation must reconcile these contrasting factors. In creating this Recommendation the BPWG has determined that Content Transformation proxies should respect Content Providers intentions, where they are expressed, but may allow users to choose other representations, except where Content Providers specifically prohibit this.
The BPWG recognizes that there is neither a systematic vocabulary for Content Provider Intentions, nor a systematic means of expression of such intentions. There is scope for further work in this area (see J Scope for Future Work ).
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."] [ Definition : "A identification. 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] .
Transforming proxies can carry out a wide variety of operations. In this document we categorize these operations as follows:
Alteration of Requests
Transforming proxies process requests in a number of ways,
especially replacement of various request headers header fields
to avoid HTTP 406 Status responses (the
(if a server can not provide content
in that is
compatible with the format
requested) original HTTP request header
fields) and at user request.
Alteration of Responses
There are three classes of operation on responses:
Restructuring content
[ 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.
Recoding content
[ 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).
]
Optimizing content
[ Definition :
Optimizing content includes removing redundant white space,
re-compressing images (without loss of fidelity) and compressing
for transfer.] transfer.
This document The Content Transformation Guidelines specification has
one class of products:
A Transformation Deployment is
not normative Need link to definition
the provision of non-transparent components in the path of HTTP requests and
it is inappropriate to claim
conformance responses. Provisions that
are applicable to it.
Implementors a Transformation
Deployment are identified in this document by use of the term
"transforming proxy" or "proxy" in the singular or
plural.
Normative parts of this Recommendation who wish to promote effective inter
operability document are identified by
the use of Web content will, however,
interpret "(Normative)" following
the section name. Informative parts are
identified by use of "(Non-Normative)" following the section
name.
The key words must
, must not , required ,
shall , shall not ,
should , should not ,
recommended , not
recommended ,may , and
optional in this Recommendation as described have the
meaning defined in [RFC 2119]
. .
The purpose of this section is
A Transformation Deployment conforms to
summarize these
guidelines if it follows the communication requirements of actors (transforming
proxies, origin servers, and to some extent users) to communicate
with each other. The relevant scenario involving a content
transformation proxy is as follows: Note: The interactions of
several transformation proxies are encompassed by this document,
but only statements in
a rudimentary form. The needs of these actors
are as follows: The user agent needs to be able to tell the
Content 3.4
Transformation proxy and the origin
server: Deployment
Conformance , what type
4.1 Proxy
Forwarding of mobile device and what
user agent is being used; that all Content Transformation should be
avoided. Request ,
The Content
Transformation proxy needs to be able 4.2 Proxy Forwarding of
Response to tell the origin
server: User Agent
that some degree of Content Transformation (
restructuring and recoding ) 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; 5
Testing (Normative) 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; Deployment that it is
permissible (or not) wishes to
perform Content Transformation of various
kinds; that it has media-specific representations;
claim conformance must make available
a conformance statement B Conformance Statement that
is unable or unwilling to deal
specifies the reasons for
non-compliance with any clauses
containing the request in its present
form. key words "
should " and " should
not ", "
recommended
" and " not recommended ".
The Content Transformation proxy needs
to Conformance statements
must be able sent to
tell the user agent: that it has applied
transformations public-content-transformation-conformance@w3.org
.Public archives of various kinds to the content. The Content Transformation
proxy needs to this list may be
able to interact with the user:
found at
http://lists.w3.org/Archives/Public/public-content-transformation-conformance/
.
Transforming proxies Proxies should not provide to
their users: an indication that the content being viewed has been
transformed for mobile presentation; an option to view the
original, unmodified content. intervene
in methods other than GET, POST, HEAD.
They may also provide the ability for
their users User agents sometimes issue
HTTP HEAD requests in order to make a
persistent or semi-persistent expression of preferences. Examples
of such settings are "Never transform", "Always request desktop
presentation", "Transform only determine if necessary to
avoid mis-operation" and "Compress where possible". Editorial Note:
The BPWG a resource is
studying how to clarify the scope of
"persistent" and "semi-persistent". 3.2.2 Control by Server
Transforming proxies must allow origin servers to control the
Content Transformation process. The control mechanisms include
use of HTTP conventions as discussed in
the following section ( 4 Behavior of Components ). 3.2.3 Control
by Administrative or Other Arrangements. The preferences of users
and a type and/or size that they are
capable of servers handling. A transforming proxy
may be ascertained by means
outside convert a HEAD request into a
GET request (in order to determine the scope characteristics
of this document, for example:
a transformed response that it would return
if the use by transforming proxies
of user agent subsequently issued
a disallow list of Web sites
GET request for which Content Transformation is known to diminish
the user experience of content or be
ineffective; same resource).
If the use by
transforming proxies of an allow list of Web sites for which
Content Transformation HTTP
method is known altered from HEAD to be
necessary; terms and conditions of service, as agreed between the
user and GET, proxies
should (providing such action is in accordance with normal HTTP
caching rules) cache the Content
Transformation service provider. Note: Allow and disallow lists
generally cause intractable problems response so that a second GET request for
the same content providers since there is no
mechanism for them to establish which lists they should be on, nor
any generic mechanism though which they can check or change their
status. not required (see also
4.1.4 Serving Cached
Responses 3.2.4 Resolving
Conflicting Instructions ).
There is the possibility for
conflict Other than to convert
between the desires of the content
provider HEAD 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. GET proxies must
not alter request
methods.
no-transform
directive in RequestIf 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.
the proxy should add the IP address of the
initiator Before altering aspects
of the an
HTTP request proxies need to
the end take
account of the fact that HTTP is used
as a comma separated list in an
X-Forwarded-For transport mechanism for
many applications other than "Traditional Browsing". Alteration
of HTTP header; requests for those applications can cause serious
misoperation.
Aside from the proxy usual caching
procedures defined in [RFC 2616 HTTP] ,in some
circumstances, proxies must may
behave transparently unless it
paginate responses and where this is
able positively to determine that the
user agent is case a Web browser. The
mechanism by which the proxy recognizes the user agent as
request may be for a Web browser 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 use evidence from notify the HTTP request, in
particular user that this is the
User-Agent case and Accept
headers. must
provide a simple means of retrieving a fresh
copy.
If there is no no-transform directive
present Aside from the usual procedures
defined in [RFC
2616 HTTP] proxies
should not modify the request
values of header fields other than the
proxy User-Agent ,Accept ,Accept-Charset ,Accept-Encoding ,and Accept-Language header fields and should must
not analyze whether it
intends delete header fields. It
must be possible for the server to offer transformation services reconstruct the original User Agent originated header
fields by referring to:
copying directly from the corresponding
X-Device header field values (see 4.1.5.5 Original Header Fields any knowledge it has of user preferences;
).
Other than to comply with transparent HTTP
operation, proxies should
not modify any
knowledge it has request header fields unless one of user agent capabilities (including linearization and
zoom); the following applies:
any prior knowledge it has of server
behavior, derived the user would be
prohibited from previous interaction
with accessing content as a result
of the server - and in particular to
preserve responding that the
consistency of user experience across a
sequence request is "unacceptable"
(see 4.2.5 Server Rejection of
related requests; HTTP Request );
the HTTP method of the request.
user has specifically requested a
restructured desktop
experience (see 4.1.5.3 User Selection of
Restructured Experience Proxies
should not alter HTTP requests unless: );
unaltered headers would result in
the user's request being rejected by is part of
a sequence of requests to the origin
server; an unaltered request body same
Web site and either it is technically
infeasible not consistent with
to adjust the origin server's requirements in respect
request because of Internet content type earlier interaction, or character encoding (as may happen, for example, if the
proxy has transformed an HTML form that results in this
request); because doing so preserves
consistency of user experience.
These circumstances are detailed in
the user has specifically requested a
restructured version of a desktop presentation. following sections.
Note:
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.
Proxies The
theoretical idempotency of GET requests is not always respected by
servers. In order, as far as possible, to avoid misoperation of
such content, proxies should not intervene in
methods other than GET, POST, HEAD avoid issuing duplicate requests and PUT. specifically
should not issue duplicate requests for comparison
purposes.
User agents sometimes issue HTTP HEAD
requests in order to determine if a resource is of a type and/or
size that they are capable of handling. 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. as "unacceptable" (see In this case,
the 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). response, and not a "request unacceptable"
response).
Proxies must 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 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.
When forwarding an HTTP request with
altered HTTP header fields, in addition to complying with the rules
of normal HTTP operation, proxies must include in the
request copies of the unaltered header field values in the
form "X-Device-"<original
header name> .For example, if
the User-Agent
header field has been altered, an
X-Device-User-Agent
header field must be added with
the value of the received User-Agent header
field.
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 |
Note:
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:
proxies should add the IP
address of the initiator of the request to Server the end of a comma
separated list in an X-Forwarded-For HTTP
header field;
The proxy proxies must include
a Via HTTP header field (see 4.1.6.1 Proxy Treatment of Via Header
Field ).
Via Header
FieldProxies must (in
accordance with compliance to RFC 2616)
include a Via HTTP header field indicating its
presence. The proxy their presence
and should indicate its presence and capabilities their ability to transform content by including a
comment in the Via HTTP header field consisting of the URI "http://www.w3.org/2008/04/ct". Editorial Note1k: Need
to put something at the end of the rainbow in case the URI is ever
resolved. "http://www.w3.org/ns/ct".
When forwarding Via headers header fields,
proxies should not alter them in any way. by removing
comments from them.
Note:
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 has altered HTTP headers
In the proxy following,
proxies must include
copies of the unaltered headers in the request in check for the form
presence of equivalent
"X-Device-"<original header name>
. For example, <meta
http-equiv>it has altered the
User-Agent header, an
X-Device-User-Agent relevant HTTP
header field is not present.
Proxies must should
not be added with
intervene in the value of response if
the received User-Agent header.
request method was not HEAD, GET or
POST.
Servers Proxies should
must respond with a 406 HTTP Status if provide a request can not be
satisfied with means for users to
express preferences for inhibiting content that meets the criteria specified transformation even when content transformation has been
chosen by values of request HTTP
headers (and not the user as the
default behavior. Those preferences must be maintained
on a 200 Status). user by user and Web site by Web site basis.
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-transformIf the server varies its presentation
according to examination of received HTTP headers then it must
include response includes a
Vary Cache-Control: no-transformHTTP 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).
Cache-Control: no-transform The server Proxies must
may include a Cache-Control: no-transform directive if one
is received from the user agent. Note: Including a
use Cache-Control:
no-transform directive can disrupt the
behavior of WAP/WML proxies, because it can inhibit such proxies
from converting WML to WMLC.
inhibit transformation by further
proxies.
Servers Proxies may base their actions on knowledge of behavior of specific
transforming proxies, treat responses
with an HTTP 200 Status as identified
in a Via header, but should not choose a Content-Type for their
response based on their assumptions about the heuristic behavior of
any intermediaries. (e.g. a server should not choose content-type:
application/vnd.wap.xhtml+xml solely on the basis that
though they were responses with an HTTP 406
Status if it suspects has determined that proxies
will not transform the content
of this type). (e.g. "Your browser is not supported") is equivalent to
a response with an HTTP 406 Status.
Vary
HTTP Header FieldIf 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.
In the absence of a Vary or
no-transform directive (or a meta
HTTP-Equiv element containing Cache-Control:
no-transform ) the proxy should apply
heuristics to the content to determine whether it is appropriate to
restructure or recode it (in the presence of such directives,
heuristics proxies should
not be used.) Examples
transform content matching any of
heuristics: the
following rules unless the user has specifically requested
transformation:
The server has previously shown that
it the content is contextually aware, even if HTML and contains <link rel="alternate"
media="handheld"/> with a
reference to the present response does
not indicate this; current
representation ;
the Content-Type DOCTYPEor 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
content (if it has one) indicates
XHTML-MP, XHTML Basic, WML or iMode as
listed in D DOCTYPEs Associated with
Mobile 1.0//EN" "-//W3C//DTD XHTML Basic
1.1//EN" and "-//W3C//DTD XHTML Basic 1.0//EN"); Content ;
the user agent Content-Type has linearization or zoom capabilities or other features
which allow it to present the content unaltered; 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) indicates that header field) matches a pattern listed in E URI Patterns Associated with Mobile Web
Sites ;
the response contains a resource
that is intended referenced as
an
included resource suitable
for mobile use (e.g. the domain
"handheld" in a resource that was itself
handled transparently;
a claim of mobileOK Basic [mobileOK Basic
Tests] conformance is
*.mobi, wap.*, m.*, mobile.* or
indicated (see [mobileOK
Scheme] for how such a claim may be
indicated).
Other factors that a proxy may take into account:
The Web site (see note ) has previously shown that it is contextually aware,
even if the leading portion of
present response does not indicate
this;
the path is /m/ user agent has features (such as linearization or
/mobile/); zoom)
that allow it to present the content unaltered;
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.
Note:
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.
Note:
In this document two
URIs have the scheme Same-Origin if the
https schemehost
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.
Note:
For clarity it is emphasized that it
can is not
possible for a transforming proxy to transform content accessed via an HTTPS link without breaking
end-to-end security.
Interception of HTTPS and the
content, if circumstances in which it meets might be permissible
is not a "mobile" question, as such, but is highly pertinent to
this document. The BPWG is aware that interception of HTTPS happens
in many networks today. Interception of HTTPS is inherently
problematic and may be unsafe. The BPWG would like to refer to
protocol based "two party consent" mechanisms, but such mechanisms
do not exist at the following
provision. time of writing of this
document.
The practice of intercepting HTTPS links is strongly NOT RECOMMENDED .
If the a
proxy does rewrite such rewrites HTTPS links, it must
advise the user of the security implications of doing so and
must provide the option to avoid decryption bypass
it and transformation of the
resources to communicate with the
links refer to. server directly.
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 HTTP behavior and other than as
noted below. directive.
If the a
proxy determines that rewrites HTTPS links, replacement links
must have the resource
scheme https .
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.
Operators of transforming
content transformation proxies
should make available interfaces that facilitate testing an interface through which the functions of
Web sites accessed the proxy can be exercised. The operations
possible through them and
this interface should must
make cover those
necessary to settle the outcome of all conformance statements
listed in section B.
The interface must be reachable
from terminals with browsing capabilities connected to the Web via
a conventional Internet access environment at the tester's
premises; accessing the interface may necessitate
adjusting standard Web browsing configuration parameters --
such interfaces as specifying a proxy IP address and port on a desktop
browser, or activating a WAP setting on a mobile browser.
Such access must be granted under fair, reasonable and non-discriminatory conditions. In particular:
it is available through normal Internet to
all, worldwide, whether or not they are W3C Members;
it does not impose any further conditions
or restrictions on the use of any technology, intellectual property
rights, or other restrictions on behaviour of the tester, but may
include reasonable, customary terms relating to operation or
maintenance of the relationship between tester and proxy operator
such as the following: choice of law and dispute resolution,
confidentiality of parameters to access paths. the interface,
disclaimer of liability.
Editorial Note: Update to final location
See http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/ics-090923
application/vnd.wap.xhtml+xml
text/vnd.wap.wml
application/vnd.wap.wmlc
text/vnd.wap.wml+xml
text/vnd.wap.wmlscript
application/vnd.wap.wmlscriptc
image/vnd.wap.wbmp
application/vnd.wap.wbxml
application/vnd.wap.multipart.mixed
application/vnd.wap.multipart.related
application/vnd.wap.multipart.alternative
application/vnd.wap.multipart.form-data
image/x-up-wpng
image/x-up-bmp
-//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
-//OPENWAVE//DTD XHTML 1.0//EN
-//OPENWAVE//DTD XHTML Mobile 1.0//EN
-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.0) 1.0//EN
-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.1) 1.0//EN
-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.0) 1.0//EN
-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.1) 1.0//EN
-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.2) 1.0//EN
-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.3) 1.0//EN
-//W3C//DTD Compact HTML 1.0 Draft//EN
-//BBSW//DTD Compact HTML 2.0//EN
-//WAPFORUM//DTD WML 1.0//EN
-//WAPFORUM//DTD WML 1.1//EN
-//WAPFORUM//DTD WML 1.2//EN
-//WAPFORUM//DTD WML 1.3//EN
-//WAPFORUM//DTD WML 2.0//EN
-//PHONE.COM//DTD WML 1.1//EN
-//OPENWAVE.COM//DTD WML 1.3//EN
Using the notation defined in [POWDER Resource Grouping]:
<iriset> <includehosts>mobi</includehosts> </iriset>
User expression of preferences is referred to in several sections in this document. Those sections are:
User preferences are also referred to non-normatively under H.1.4 Varying Representations .
Note:
The following examples refer to requests with the GET method.
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:
If the response
contains Vary:
User-Agent ,an appropriate
link element or header field, or Cache-Control: no-transform ,forward it
Otherwise assess whether the 200 response is a form of "Request Unacceptable"
If it is not, forward it
If it is, request again with altered header fields
Proxy receives a request for resource P that it has not encountered before
Proxy forwards this request
Response is 200 OK containing the text "Unsupported browser. Please get a different one or use a CT proxy."
Proxy determines that this equates to a 406 Status and requests the resource from the origin server again with altered header fields (emulating a well known desktop browser)
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
Based on evidence from the
previous interaction (e.g. that there was no
Vary header field, that the response was not targeted at only
the previous user in that there was no Cache-Control: private directive) the CT proxy forwards the request with
altered header fields
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
Proxy receives a request for resource P
Proxy forwards request with original header fields
Response is 200 OK
with Vary:
User-Agent and
<link type="alternate"
media="handheld" href="P#id" /> where id is a document local reference
Proxy forwards response as designed specifically for the requesting device
Proxy receives a request for resource P
Proxy forwards request with original header fields
Response is 200 OK
with <link type="alternate"
media="handheld" href="Q" /> and Q is not P
Proxy requests Q 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.
Servers should consider using an HTTP 406 Status (and not an HTTP 200 Status) if a request cannot be satisfied with content that meets the criteria specified by values of the HTTP request header fields. However, some browsers do not display the content of HTTP 406 Status responses.
Servers should consider using an HTTP 403
Status if concerned that the security of a link assumed to be
private has been compromised (for example this may be inferred by
the presence of a Via HTTP header field
in an HTTPS request).
Cache-Control: no-transformServers should consider including a
Cache-Control:
no-transform directive if one is
received in the HTTP request, as it may be an indication that the
client does not wish to receive a transformed response.
Include a Cache-Control: no-transform directive if, for any reason, transformation of the
response is prohibited.
Note:
Including
a Cache-Control:
no-transform directive can
disrupt the behavior of WAP Gateways, because it can inhibit such
proxies from converting WML to WMLC.
It is good practice to take account of user agent capabilities and formulate an appropriate experience according to those capabilities. It is good practice to provide a means for users to select among available representations, to default to the last selected representation and to provide a means of changing the selection.
Vary HTTP Header FieldIf 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 .
There are a number of well-known examples of solutions that seem to their users as though they are using a browser, but because the client software communicates using proprietary protocols and techniques, it is the combination of the client and the network component that is regarded as the HTTP User Agent. The communication between the client and the network component is therefore out of scope of this document.
Additionally, where some kind of administrative arrangement exists between a transforming proxy and an origin server for the purposes of transforming content on the origin server's behalf, this is also out of scope of this document.
In both of the above cases, it is good practice to adhere to the provisions of this document in respect of providing information about the device and the original IP address.
The BPWG believes that 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.
link
HTTP Header FieldThe BPWG believes that the link HTTP header
field which was removed from
recent drafts of HTTP, HTTP/1.1, and which is under discussion for
re-introduction, reintroduction, would represent a more general and
flexible mechanism than use of the HTML link element,
as discussed in this recommendation.
The process of adapting content at the origin server, or transforming it in a proxy is likely to have a dependency on a repository of device descriptions. An origin server's willingness to allow a transforming proxy to transform content may depend on its evaluation of the trustworthiness of device description data that is being used. There is scope for enhancement of the trust relationship by some means of indicating this.
There is scope for further work to define how multiple proxies may interoperate. A common case of multiple proxies is where a network provider transforming proxy and a search engine transforming proxy are both present.
The B BPWG
believes that amendments to HTTP are needed to improve the
interoperability of transforming proxies. For example, HTTP does
not provide a way to distinguish between prohibition of any kind of
transformation and the prohibition only of restructuring (and not
recoding or compression).
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 editor acknowledges contributions of various kinds from members of the Mobile Web Best Practices Working Group and earlier from the Content Transformation Task Force of that group.
The editor acknowledges significant written contributions from: