You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1653 lines
102 KiB
1653 lines
102 KiB
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<title>Guidelines for Web Content Transformation Proxies 1.0</title>
|
|
<style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
.new
|
|
{
|
|
background-color: #FFFF80;
|
|
color: inherit;
|
|
}
|
|
|
|
.requirement
|
|
{
|
|
background-color: #DDDD80;
|
|
color: inherit;
|
|
border: 1px black solid;
|
|
padding: 0.5em;
|
|
}
|
|
|
|
.requirement:before
|
|
{
|
|
content: "Requirement: ";
|
|
font-weight: bold;
|
|
}
|
|
|
|
.image
|
|
{
|
|
text-align: center;
|
|
}
|
|
|
|
.flow1
|
|
{
|
|
font-family: monospace;
|
|
font-size:smaller
|
|
}
|
|
|
|
.flow2
|
|
{
|
|
margin-left: 2em;
|
|
font-family: monospace;
|
|
font-size:smaller
|
|
}
|
|
|
|
.flow3
|
|
{
|
|
margin-left: 4em;
|
|
font-family: monospace;
|
|
font-size:smaller
|
|
}
|
|
|
|
pre
|
|
{
|
|
border:none;
|
|
}</style>
|
|
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
|
|
</head>
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"/></a></p>
|
|
<h1><a name="title" id="title"></a>Guidelines for Web Content Transformation Proxies 1.0</h1>
|
|
|
|
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group Note 26 October 2010</h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd>
|
|
<a href="http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/">http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/</a>
|
|
</dd>
|
|
<dt>Latest version:</dt>
|
|
<dd>
|
|
<a href="http://www.w3.org/TR/ct-guidelines/">http://www.w3.org/TR/ct-guidelines/</a>
|
|
</dd>
|
|
<dt>Previous version:</dt>
|
|
<dd>
|
|
<a href="http://www.w3.org/TR/2010/CR-ct-guidelines-20100617/">http://www.w3.org/TR/2010/CR-ct-guidelines-20100617/</a>
|
|
</dd>
|
|
<dt>Editor:</dt>
|
|
<dd>Jo Rabin, Invited Expert (and before at mTLD Top Level Domain, dotMobi)</dd>
|
|
</dl>
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
|
|
</p>
|
|
</div>
|
|
<hr />
|
|
<div>
|
|
|
|
<h2><a name="abstract" id="abstract"></a>Abstract</h2>
|
|
<p>This document provides guidance to Content Transformation proxies as to whether and how to transform Web content.</p>
|
|
<p>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.
|
|
</p>
|
|
<p>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.
|
|
</p>
|
|
<p>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.
|
|
</p>
|
|
<p>Important considerations regarding the impact on security are highlighted.</p>
|
|
</div>
|
|
<div>
|
|
<h2><a name="status" id="status"></a>Status of this Document</h2>
|
|
|
|
<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This document was developed by the <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> as part of the <a href="http://www.w3.org/Mobile/">Mobile Web Initiative</a>.</p>
|
|
|
|
<p>This document was expected to become a W3C Recommendation and was published as a W3C Candidate Recommendation on <a href="http://www.w3.org/TR/2010/CR-ct-guidelines-20100617/" title="Candidate Recommendation of the Guidelines for Web Content Transformation Proxies published on 17 June 2010">17 June 2010</a>. As of October 2010, the Mobile Web Best Practices Working Group acknowledges the lack of existing implementations. Nevertheless, it also believes that the guidelines establish a framework acceptable by all parties involved.</p>
|
|
|
|
<p>The Mobile Web Best Practices Working Group eventually resolved to discontinue the work on this document and to publish it as a <strong>Working Group Note</strong>. The Working Group hopes that this Note may serve as a basis for discussion and negotiation among players.</p>
|
|
|
|
<p>Other than changes to this section, the document has not changed since its publication as a W3C Candidate Recommendation. In particular, the use of normative language has been kept as-is.</p>
|
|
|
|
<p>Comments on this document may be sent to the Working Group's public email list <a href="mailto:public-bpwg-comments@w3.org">public-bpwg-comments@w3.org</a> (with <a href="http://lists.w3.org/Archives/Public/public-bpwg-comments/">public archive</a>).</p>
|
|
|
|
<p>The public <a href="mailto:public-content-transformation-conformance@w3.org">public-content-transformation-conformance@w3.org</a> mailing-list (with <a href="http://lists.w3.org/Archives/Public/public-content-transformation-conformance/" title="Public archive for the public-content-transformation-conformance mailing-list">public archive</a>) that had been created to gather implementation feedback may still be used for that purpose. The Working Group also invites people willing to contribute to the <a href="http://dev.w3.org/2010/ct-guidelines/test-suite/">test case repository</a> to let themselves known on the <a href="mailto:public-bpwg-comments@w3.org">public-bpwg-comments@w3.org</a> public mailing-list, noting however that no further work is anticipated on that topic within the group as of October 2010. Please check the <a href="http://dev.w3.org/2010/ct-guidelines/test-suite/">test case repository</a> for up-to-date information.</p>
|
|
|
|
<p>Publication as a Working Group Note 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.</p>
|
|
|
|
<p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/37584/status">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
|
|
|
|
</div>
|
|
<div class="toc">
|
|
|
|
<h2><a name="contents" id="contents"></a>Table of Contents</h2>
|
|
<p class="toc">1 <a href="#sec-introduction">Introduction (Non-Normative)</a><br />
|
|
1.1 <a href="#sec-purpose">Purpose</a><br />
|
|
1.2 <a href="#sec-audience">Audience</a><br />
|
|
1.3 <a href="#sec-scope">Scope</a><br />
|
|
1.4 <a href="#sec-principles">Principles</a><br />
|
|
1.4.1 <a href="#sec-iab-considerations">IAB Considerations</a><br />
|
|
1.4.2 <a href="#sec-priority-of-intention">Priority of Intention</a><br />
|
|
2 <a href="#sec-terminology">Terminology (Normative)</a><br />
|
|
2.1 <a href="#sec-types-of-proxy">Types of Proxy</a><br />
|
|
2.2 <a href="#sec-types-of-transformation">Types of Transformation</a><br />
|
|
2.3 <a href="#sec-informing-the-user">User Interaction</a><br />
|
|
3 <a href="#sec-conformance">Conformance (Normative)</a><br />
|
|
3.1 <a href="#sec-classes-of-product">Classes of Product</a><br />
|
|
3.2 <a href="#sec-normative-and-informative-parts">Normative and Informative Parts</a><br />
|
|
3.3 <a href="#sec-rfc2119">Normative Language for Conformance Requirements</a><br />
|
|
3.4 <a href="#sec-transformation-deployment-conformance">Transformation Deployment Conformance</a><br />
|
|
4 <a href="#sec-Components">Behavior of Components (Normative)</a><br />
|
|
4.1 <a href="#sec-ProxyReqest">Proxy Forwarding of Request</a><br />
|
|
4.1.1 <a href="#sec-applicable-HTTP-methods">Applicable HTTP Methods</a><br />
|
|
4.1.2 <a href="#sec-request-no-transform">no-transform directive in Request</a><br />
|
|
4.1.3 <a href="#sec-non-web-browsers">Treatment of Requesters that are not Web browsers</a><br />
|
|
4.1.4 <a href="#sec-serving-cached-responses">Serving Cached Responses</a><br />
|
|
4.1.5 <a href="#sec-altering-header-values">Alteration of HTTP Header Field Values</a><br />
|
|
4.1.5.1 <a href="#sec-content-tasting">Content Tasting</a><br />
|
|
4.1.5.2 <a href="#sec-avoiding-request-unacceptable">Avoiding "Request Unacceptable" Responses</a><br />
|
|
4.1.5.3 <a href="#sec-user-selection">User Selection of Restructured Experience</a><br />
|
|
4.1.5.4 <a href="#sec-sequence-of-requests">Sequence of Requests</a><br />
|
|
4.1.5.5 <a href="#sec-original-headers">Original Header Fields</a><br />
|
|
4.1.6 <a href="#sec-additional-headers">Additional HTTP Header Fields</a><br />
|
|
4.1.6.1 <a href="#sec-via-headers">Proxy Treatment of Via Header Field</a><br />
|
|
4.2 <a href="#sec-Proxy-Response">Proxy Forwarding of Response to User Agent</a><br />
|
|
4.2.1 <a href="#sec-administrative-arrangements">User Preferences</a><br />
|
|
4.2.2 <a href="#sec-receipt-of-cache-control-no-transform">Receipt of Cache-Control: no-transform</a><br />
|
|
4.2.3 <a href="#sec-proxy-use-of-no-transform">Use of Cache-Control: no-transform</a><br />
|
|
4.2.4 <a href="#sec-unacceptable-response">Server Rejection of HTTP Request</a><br />
|
|
4.2.5 <a href="#sec-receipt-of-vary-header">Receipt of Vary HTTP Header Field</a><br />
|
|
4.2.6 <a href="#sec-receipt-of-link-to-handheld">Link to "handheld" Representation</a><br />
|
|
4.2.7 <a href="#sec-WML-content">WML Content</a><br />
|
|
4.2.8 <a href="#sec-proxy-decision-to-transform">Proxy Decision to Transform</a><br />
|
|
4.2.8.1 <a href="#sec-alteration-of-response">Alteration of Response</a><br />
|
|
4.2.8.2 <a href="#sec-link-rewriting">Link Rewriting</a><br />
|
|
4.2.8.3 <a href="#sec-https-link-rewriting">HTTPS Link Rewriting</a><br />
|
|
5 <a href="#sec-testing">Testing (Normative)</a><br />
|
|
|
|
</p>
|
|
|
|
<h3><a name="appendices" id="appendices"></a>Appendices
|
|
</h3>
|
|
<p class="toc">A <a href="#sec-references">References</a><br />
|
|
B <a href="#sec-ConformanceStatement">Conformance Statement</a><br />
|
|
C <a href="#sec-Mobile-Content-Types">Internet Content Types associated with Mobile Content</a><br />
|
|
D <a href="#sec-Data-Content-Types">Internet Content Types associated with Data Content</a><br />
|
|
E <a href="#sec-Mobile-DOCTYPES">DOCTYPEs Associated with Mobile Content</a><br />
|
|
F <a href="#sec-Mobile-URI-Patterns">URI Patterns Associated with Mobile Web Sites</a><br />
|
|
G <a href="#sec-Summary-User-Preference-Handling">Summary of User Preference Handling</a><br />
|
|
H <a href="#sec-example-transformation-interactions">Example Transformation Interactions</a> (Non-Normative)<br />
|
|
H.1 <a href="#sec-basic-content-tasting">Basic Content Tasting by Proxy</a><br />
|
|
H.2 <a href="#sec-proxy-a-priori-knowledge">Optimization based on Previous Server Interaction</a><br />
|
|
H.3 <a href="#sec-optimization-previous-interaction">Optimization based on Previous Server Interaction, Server has Changed its
|
|
Operation</a><br />
|
|
H.4 <a href="#sec-representation-intended">Server Response Indicating that this Representation is Intended for the Target
|
|
Device</a><br />
|
|
H.5 <a href="#sec-another-representation">Server Response Indicating that another Representation is Intended for the
|
|
Target Device</a><br />
|
|
I <a href="#sec-guidance-origin-servers">Informative Guidance for Origin Servers</a> (Non-Normative)<br />
|
|
I.1 <a href="#sec-ServerResponse">Server Response to Proxy</a><br />
|
|
I.1.1 <a href="#sec-server-use-of-406">Use of HTTP 406 Status</a><br />
|
|
I.1.2 <a href="#sec-server-use-of-403">Use of HTTP 403 Status</a><br />
|
|
I.1.3 <a href="#sec-cache-control-no-transform">Server Origination of Cache-Control: no-transform</a><br />
|
|
I.1.4 <a href="#sec-varying-representations">Varying Representations</a><br />
|
|
I.1.4.1 <a href="#sec-use-of-vary-header">Use of Vary HTTP Header Field</a><br />
|
|
I.1.4.2 <a href="#sec-use-of-link-element">Indication of Intended Presentation Media Type of Representation</a><br />
|
|
J <a href="#sec-applicability">Applicability to Transforming Solutions which are Out of Scope</a> (Non-Normative)<br />
|
|
K <a href="#sec-scope-for-future-work">Scope for Future Work</a> (Non-Normative)<br />
|
|
K.1 <a href="#sec-powder">POWDER</a><br />
|
|
K.2 <a href="#sec-link-http-header">link HTTP Header Field</a><br />
|
|
K.3 <a href="#sec-sources-devinfo">Sources of Device Information</a><br />
|
|
K.4 <a href="#sec-inter-proxy-comm">Inter Proxy Communication</a><br />
|
|
K.5 <a href="#sec-explicit-consent">Explicit Consent</a><br />
|
|
K.6 <a href="#sec-amendment-http">Amendment to and Refinement of HTTP</a><br />
|
|
L <a href="#sec-acknowledgements">Acknowledgments</a> (Non-Normative)<br />
|
|
|
|
</p>
|
|
</div>
|
|
<hr />
|
|
<div class="body">
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-introduction" id="sec-introduction"></a>1 Introduction (Non-Normative)</h2>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-purpose" id="sec-purpose"></a>1.1 Purpose
|
|
</h3>
|
|
<p>Within this document <em>Content Transformation</em> refers to the
|
|
manipulation of requests to, and responses from, an origin 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 the request.
|
|
</p>
|
|
<p>The W3C 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.
|
|
</p>
|
|
<p>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 <a href="http://www.w3.org/TR/di-gloss/#def-functional-user-experience"
|
|
>"functional user experience"</a>
|
|
<a href="#ref-DIGLOSS">[Device Independence Glossary]</a> 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 <em>functional user
|
|
experience</em> when perceived on many mobile devices.
|
|
</p>
|
|
<p>It is stressed that this document is unlikely to be the last word on this topic. As noted below (<a href="#sec-scope"><span class="specref">1.3 Scope</span></a>) it is out of scope of this document to provide a comprehensive solution to control of transforming proxies, though such
|
|
a solution would appear to be needed. The document is an attempt to improve a situation at a point in time where there appears
|
|
to be disregard of the provisions of HTTP - and is primarily a reminder and an encouragement to follow those provisions more
|
|
closely.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-audience" id="sec-audience"></a>1.2 Audience
|
|
</h3>
|
|
<p>The audience for this document is creators of Content Transformation proxies and
|
|
purchasers and operators of such proxies. The document also contains non-normative guidance for content providers whose services
|
|
may be accessed by means of such proxies.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-scope" id="sec-scope"></a>1.3 Scope
|
|
</h3>
|
|
<p>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) using HTTP. Clients that interact with proxies using
|
|
mechanisms other than HTTP (and that typically involve the download of a special
|
|
client) are out of scope, and are considered to be a distributed user agent.
|
|
Proxies which are operated in the control of 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.
|
|
</p>
|
|
<p>The W3C <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> (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 header fields, directives and behaviors
|
|
must be respected, and as far as is practical, no extensions to <a href="#ref-HTTP">[RFC 2616 HTTP]</a> are to be used.
|
|
</p>
|
|
<p>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).
|
|
</p>
|
|
<p>Moral, legal and other similar questions are not in scope of this document. The BPWG does not have authority or expertise
|
|
to comment one way or another about setting precedent or authorising any particular behavior or its absence.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-principles" id="sec-principles"></a>1.4 Principles
|
|
</h3>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-iab-considerations" id="sec-iab-considerations"></a>1.4.1 IAB Considerations
|
|
</h4>
|
|
<p>The BPWG made reference to Internet Architecture Board (IAB) work on "Open Pluggable Edge Services" <a href="#ref-OPES">[RFC 3238 OPES]</a> 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.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-priority-of-intention" id="sec-priority-of-intention"></a>1.4.2 Priority of Intention
|
|
</h4>
|
|
<p>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.
|
|
</p>
|
|
<p>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 <a href="#sec-scope-for-future-work"><span class="specref">K Scope for Future Work</span></a>).
|
|
</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-terminology" id="sec-terminology"></a>2 Terminology (Normative)</h2>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-types-of-proxy" id="sec-types-of-proxy"></a>2.1 Types of Proxy
|
|
</h3>
|
|
<p>Alteration of HTTP requests and responses is not prohibited by HTTP other than in
|
|
the circumstances referred to in <a href="#ref-HTTP">[RFC 2616 HTTP]</a>
|
|
<a href="http://tools.ietf.org/html/rfc2616#section-13.5.2">Section 13.5.2</a> and <a href="http://tools.ietf.org/html/rfc2616#section-14.9.5">Section 14.9.5</a>.
|
|
</p>
|
|
<p>HTTP defines two types of proxy: transparent proxies and non-transparent proxies.
|
|
As discussed in <a href="#ref-HTTP">[RFC 2616 HTTP]</a>
|
|
<a href="http://tools.ietf.org/html/rfc2616#section-1.3">Section 1.3, Terminology</a>:
|
|
</p>
|
|
<p>
|
|
<a name="term-transparent" id="term-transparent" title="transparent proxy"
|
|
></a>"A <b>transparent
|
|
proxy</b> is a proxy that does not modify the request or response
|
|
beyond what is required for proxy authentication and identification.
|
|
<a name="term-non-transparent" id="term-non-transparent"
|
|
title="non-transparent proxy"
|
|
></a>A
|
|
<b>non-transparent proxy</b> 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."
|
|
</p>
|
|
<p>This document elaborates the behavior of non-transparent proxies, when used for
|
|
Content Transformation in the context discussed in <a href="#ref-CT-Landscape">[CT Landscape]</a>.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-types-of-transformation" id="sec-types-of-transformation"
|
|
></a>2.2 Types of Transformation
|
|
</h3>
|
|
<p>Transforming proxies can carry out a wide variety of operations. In this document
|
|
we categorize these operations as follows (noting that these are general concepts that we do not formalize further):
|
|
</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>Alteration of Requests</p>
|
|
<p>Transforming proxies process requests in a number of ways, especially
|
|
replacement of various request header fields to avoid HTTP 406 Status
|
|
responses (if a server can not provide content that is compatible with
|
|
the original HTTP request header fields) and at user request.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>Alteration of Responses</p>
|
|
<p>There are three classes of operation on responses:</p>
|
|
<ol class="enumla">
|
|
<li>
|
|
<p>Restructuring content </p>
|
|
<p>
|
|
<a name="term-restructuring" id="term-restructuring" title="restructuring"
|
|
></a><b>Restructuring</b> 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. 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
|
|
(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 also includes rewriting URIs so that subsequent
|
|
requests are routed via the proxy handling the response.
|
|
|
|
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>Recoding content</p>
|
|
<p>
|
|
<a name="term-recoding" id="term-recoding" title="recoding"></a><b>Recoding</b> 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).
|
|
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>Optimizing content</p>
|
|
<p>
|
|
<a name="term-optimizing" id="term-optimizing" title="optimizing"></a><b>Optimizing</b> content includes removing redundant
|
|
white space, re-compressing images (without loss of
|
|
fidelity) and compressing for transfer.
|
|
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-informing-the-user" id="sec-informing-the-user"></a>2.3 User Interaction
|
|
</h3>
|
|
<p>At various points in this document there is reference to "notifying the user", "informing the user" - in general making the
|
|
user aware that a situation exists or interacting with the user to solicit a choice of options. The expectation is that such
|
|
user interaction is conducted in a way that allows the user to perceive and interact with such information or choices in the
|
|
same way as they interact with the Web sites that they are visiting.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-conformance" id="sec-conformance"></a>3 Conformance (Normative)</h2>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-classes-of-product" id="sec-classes-of-product"></a>3.1 Classes of Product
|
|
</h3>
|
|
<p>The Content Transformation Guidelines specification has one class of products:</p>
|
|
<dl>
|
|
<dt class="label">Transformation Deployment</dt>
|
|
<dd>
|
|
<p>A Transformation Deployment is the provision of <a title="non-transparent proxy" href="#term-non-transparent">non-transparent</a> 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.
|
|
</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-normative-and-informative-parts"
|
|
id="sec-normative-and-informative-parts"
|
|
></a>3.2 Normative and Informative Parts
|
|
</h3>
|
|
<p>Normative parts of this document are identified by the use of "(Normative)"
|
|
following the section name. Informative parts are identified by use of
|
|
"(Non-Normative)" following the section name.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-rfc2119" id="sec-rfc2119"></a>3.3 Normative Language for Conformance Requirements
|
|
</h3>
|
|
<p>The key words <strong>must</strong>, <strong>must not</strong>,
|
|
<strong>required</strong>, <strong>shall</strong>, <strong>shall
|
|
not</strong>, <strong>should</strong>, <strong>should not</strong>,
|
|
<strong>recommended</strong>, <strong>not recommended</strong>, <strong>may</strong>, and
|
|
<strong>optional</strong> in this Recommendation have the meaning defined
|
|
in <a href="#ref-rfc-2119">[RFC 2119]</a>.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-transformation-deployment-conformance"
|
|
id="sec-transformation-deployment-conformance"></a>3.4 Transformation Deployment Conformance
|
|
</h3>
|
|
<p>A Transformation Deployment conforms to these guidelines if it follows the
|
|
statements in <a href="#sec-transformation-deployment-conformance"><span class="specref">3.4 Transformation Deployment Conformance</span></a>, <a href="#sec-ProxyReqest"><span class="specref">4.1 Proxy Forwarding of Request</span></a>, <a href="#sec-Proxy-Response"><span class="specref">4.2 Proxy Forwarding of Response to User Agent</span></a> and <a href="#sec-testing"><span class="specref">5 Testing (Normative)</span></a>.
|
|
</p>
|
|
<p>A Transformation Deployment that wishes to claim conformance <strong>must</strong> make available a conformance statement <a href="#sec-ConformanceStatement"><span class="specref">B Conformance Statement</span></a> that specifies the reasons for non-compliance with any clauses containing the key words "<strong>should</strong>" and "<strong>should not</strong>", "<strong>recommended</strong>" and "<strong>not recommended</strong>".
|
|
</p>
|
|
<p>Conformance statements <strong>must</strong> be sent to <a href="mailto:public-content-transformation-conformance@w3.org">public-content-transformation-conformance@w3.org</a>. Public archive of this list may be found at <a href="http://lists.w3.org/Archives/Public/public-content-transformation-conformance/">http://lists.w3.org/Archives/Public/public-content-transformation-conformance/</a>.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-Components" id="sec-Components"></a>4 Behavior of Components (Normative)</h2>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-ProxyReqest" id="sec-ProxyReqest"></a>4.1 Proxy Forwarding of Request
|
|
</h3>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-applicable-HTTP-methods" id="sec-applicable-HTTP-methods"
|
|
></a>4.1.1 Applicable HTTP Methods
|
|
</h4>
|
|
<p>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 <strong>may</strong> convert a HEAD request into a GET
|
|
request (in order to determine the characteristics of a transformed response
|
|
that it would return if the user agent subsequently issued a GET request for
|
|
the same resource).
|
|
</p>
|
|
<p>If the HTTP method is altered from HEAD to GET, proxies
|
|
<strong id="ta-49078">should</strong> (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 <a href="#sec-serving-cached-responses"><span class="specref">4.1.4 Serving Cached Responses</span></a>).
|
|
</p>
|
|
<p>Other than to convert between HEAD and GET proxies <strong id="ta-59418">must not</strong> alter request methods.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-request-no-transform" id="sec-request-no-transform"></a>4.1.2 <code>no-transform</code> directive in Request
|
|
</h4>
|
|
<p>If the request contains a <code>Cache-Control: no-transform</code> directive, proxies <strong id="ta-41855">must not</strong> alter the request other than to comply with <a title="transparent proxy" href="#term-transparent">transparent</a> HTTP behavior defined in <a href="#ref-HTTP">[RFC 2616 HTTP]</a> sections <a href="http://tools.ietf.org/html/rfc2616.html#section-14.9.5">section 14.9.5</a> and <a href="http://tools.ietf.org/html/rfc2616.html#section-13.5.2">section 13.5.2</a> and to add header fields as described in <a href="#sec-additional-headers"><span class="specref">4.1.6 Additional HTTP Header Fields</span></a> below.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>An example of the use of <code>Cache-Control: no-transform</code> is the
|
|
issuing of asynchronous HTTP requests, perhaps by means of
|
|
XMLHttpRequest <a href="#ref-XHR">[XHR]</a>, which may include such a
|
|
directive in order to prevent transformation of both the request and the
|
|
response.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-non-web-browsers" id="sec-non-web-browsers"></a>4.1.3 Treatment of Requesters that are not Web browsers
|
|
</h4>
|
|
<p>Before altering aspects of HTTP requests and responses proxies need to take account of the fact that HTTP is used as a transport
|
|
mechanism for many applications other than "Traditional Browsing". Increasingly browser based applications involve exchanges
|
|
of data using XMLHttpRequest (see <a href="#sec-proxy-decision-to-transform"><span class="specref">4.2.8 Proxy Decision to Transform</span></a>) and alteration of such exchanges is likely to cause misoperation.
|
|
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-serving-cached-responses" id="sec-serving-cached-responses"
|
|
></a>4.1.4 Serving Cached Responses
|
|
</h4>
|
|
<p>Aside from the usual caching procedures defined in <a href="#ref-HTTP">[RFC 2616 HTTP]</a>, in some circumstances, proxies <strong>may</strong> paginate responses and
|
|
where this is the case a request may be for a subsequent page of a
|
|
previously requested resource. In this case proxies <strong>may</strong>
|
|
for the sake of consistency of representation serve stale data but when
|
|
doing so <strong id="ta-17538">should</strong> notify the user that this is the case and
|
|
<strong id="ta-19789">must</strong> provide a simple means of retrieving a fresh
|
|
copy.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-altering-header-values" id="sec-altering-header-values"></a>4.1.5 Alteration of HTTP Header Field Values
|
|
</h4>
|
|
<p>Other than the modifications required by <a href="#ref-HTTP">[RFC 2616 HTTP]</a> proxies <strong id="ta-19234">should not</strong> modify the values of header fields other than
|
|
the <code>User-Agent</code>, <code>Accept</code>, <code>Accept-Charset</code>, <code>Accept-Encoding</code>, and <code>Accept-Language</code> header fields
|
|
and <strong id="ta-13875">must not</strong> delete header fields (see <a href="#sec-original-headers"><span class="specref">4.1.5.5 Original Header Fields</span></a>).
|
|
|
|
</p>
|
|
<p>Other than to comply with <a title="transparent proxy" href="#term-transparent">transparent</a> HTTP operation, proxies <strong id="ta-5564">should not</strong> modify <em>any</em> request header fields unless one of the following applies:
|
|
</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>the user would be prohibited from accessing content as a result of
|
|
the server responding that the request is "unacceptable" (see
|
|
<a href="#sec-unacceptable-response"><span class="specref">4.2.4 Server Rejection of HTTP Request</span></a>);
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the user has specifically requested a <a title="restructuring" href="#term-restructuring">restructured</a> desktop
|
|
experience (see <a href="#sec-user-selection"><span class="specref">4.1.5.3 User Selection of Restructured Experience</span></a>);
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the request is part of a sequence of requests comprising either included resources or linked resources
|
|
on the same Web site (see <a href="#sec-sequence-of-requests"><span class="specref">4.1.5.4 Sequence of Requests</span></a>).
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
<p>These circumstances are detailed in the following sections.</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>It is emphasized that requests <strong id="ta-32212">must not</strong> be altered in the presence of <code>Cache-Control: no-transform</code> as described under <a href="#sec-request-no-transform"><span class="specref">4.1.2 no-transform directive in Request</span></a>.
|
|
</p>
|
|
</div>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p id="term-web-site">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 <strong id="ta-34769">should</strong> use heuristics including comparisons
|
|
of domain name to assess whether resources form part of the same "Web
|
|
site".
|
|
</p>
|
|
</div>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>The URI referred to in the request plays no part in
|
|
determining whether or not to alter HTTP request header field values. In
|
|
particular the patterns mentioned in
|
|
<a href="#sec-proxy-decision-to-transform"><span class="specref">4.2.8 Proxy Decision to Transform</span></a> are not material.
|
|
</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-content-tasting" id="sec-content-tasting"></a>4.1.5.1 Content Tasting
|
|
</h5>
|
|
<p>While complying with this section (<a href="#sec-altering-header-values"><span class="specref">4.1.5 Alteration of HTTP Header Field Values</span></a>) and section <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a> proxies <strong id="ta-37267">should</strong> avoid making repeated requests for the same resource.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>While HTTP does not prohibit repetition of GET requests, repeated requests place an unnecessary load on the network and server.
|
|
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-avoiding-request-unacceptable" id="sec-avoiding-request-unacceptable"
|
|
></a>4.1.5.2 Avoiding "Request Unacceptable" Responses
|
|
</h5>
|
|
<p>A proxy <strong>may</strong> reissue a request with altered HTTP header field
|
|
values if a previous request with unaltered values resulted in the
|
|
origin server rejecting the request as "unacceptable" (see <a href="#sec-unacceptable-response"><span class="specref">4.2.4 Server Rejection of HTTP Request</span></a>). A proxy <strong>may</strong> apply heuristics of
|
|
various kinds to assess, in advance of sending unaltered header field values,
|
|
whether the request is likely to cause a "request unacceptable"
|
|
response. If it determines that this is likely then it
|
|
<strong>may</strong> alter header field values without sending unaltered
|
|
values in advance, providing that it subsequently assesses the response
|
|
as described under <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a> below,
|
|
and is prepared to reissue the request with unaltered header fields, and alter
|
|
its subsequent behavior in respect of the Web site so that unaltered
|
|
header fields are sent.
|
|
</p>
|
|
<p>A proxy <strong id="ta-8535">must not</strong> reissue a POST request as it is unsafe (see <a href="#ref-HTTP">[RFC 2616 HTTP]</a> <a href="http://tools.ietf.org/html/rfc2616#section-9.1.1">Section 9.1.1</a>).
|
|
</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-user-selection" id="sec-user-selection"></a>4.1.5.3 User Selection of Restructured Experience
|
|
</h5>
|
|
<p>Proxies <strong id="ta-38106">must</strong> assume that by default users will wish
|
|
to receive a representation prepared by the Web site.
|
|
</p>
|
|
<p>Proxies <strong>may</strong> 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
|
|
<strong>may</strong> alter header field values when requesting resources in
|
|
order to reflect that choice, but <strong id="ta-21844">must</strong>, on receipt of
|
|
an indication from a Web site that it offers alternative representations
|
|
(see <a href="#sec-use-of-link-element"><span class="specref">I.1.4.2 Indication of Intended Presentation Media Type of Representation</span></a>), inform the user of that
|
|
and allow them to select an alternative representation.
|
|
</p>
|
|
<p>Proxies
|
|
<strong id="ta-38061">must</strong> assess whether a user's expressed preference
|
|
for a restructured representation is still valid if a Web site changes
|
|
its choice of representations (see <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a>).
|
|
</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-sequence-of-requests" id="sec-sequence-of-requests"></a>4.1.5.4 Sequence of Requests
|
|
</h5>
|
|
<p>When requesting resources that are <a href="http://www.w3.org/TR/mobileOK-basic10-tests/#included_resources"
|
|
>included resources</a> (e.g. style sheets, images), proxies <strong id="ta-46682">should</strong>
|
|
make the request for such resources with the same <code>User-Agent</code> header field as the request
|
|
for the resource from which they are referenced.
|
|
</p>
|
|
<p>For the purpose of consistency of representation, proxies
|
|
<strong>may</strong> request linked resources (e.g. those referenced
|
|
using the <code>a</code> 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.
|
|
</p>
|
|
<p>When requesting linked resources that do not form part of the same Web
|
|
site as the resource from which they are linked, proxies <strong id="ta-7181">should
|
|
not</strong> base their choice of header fields on a consistency of
|
|
presentation premise.
|
|
</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-original-headers" id="sec-original-headers"></a>4.1.5.5 Original Header Fields
|
|
</h5>
|
|
<p>When forwarding an HTTP request with altered HTTP header fields, in addition to complying with the rules of normal HTTP operation,
|
|
proxies
|
|
<strong id="ta-65343">must</strong> include in the request additional fields of the form <code>"X-Device-"<original
|
|
header name></code> whose values are verbatim copies of the corresponding
|
|
unaltered header field values, so that it is possible to reconstruct the original header fields. For example, if the <code>User-Agent</code>
|
|
header field has been altered, an <code>X-Device-User-Agent</code> header field
|
|
would be added with the value of the received
|
|
<code>User-Agent</code> header field.
|
|
</p>
|
|
<p>Specifically the following mapping <strong id="ta-23178">must</strong> be used:
|
|
</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Original</th>
|
|
<th rowspan="1" colspan="1">Replacement</th>
|
|
<th rowspan="1" colspan="1">Ref</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>User-Agent</code></td>
|
|
<td rowspan="1" colspan="1"><code>X-Device-User-Agent</code></td>
|
|
<td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.43">RFC2616 Section 14.43</a>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>Accept</code></td>
|
|
<td rowspan="1" colspan="1"><code>X-Device-Accept</code></td>
|
|
<td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.1">RFC2616 Section 14.1</a>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>Accept-Charset</code></td>
|
|
<td rowspan="1" colspan="1"><code>X-Device-Accept-Charset</code></td>
|
|
<td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.2">RFC2616 Section 14.2</a>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>Accept-Encoding</code></td>
|
|
<td rowspan="1" colspan="1"><code>X-Device-Accept-Encoding</code></td>
|
|
<td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.3">RFC2616 Section 14.3</a>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>Accept-Language</code></td>
|
|
<td rowspan="1" colspan="1"><code>X-Device-Accept-Language</code></td>
|
|
<td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.4">RFC2616 Section 14.4</a>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>The <code>X-Device-</code> prefixed header names listed in this section have been provisionally registered with IANA (see <a href="http://www.iana.org/assignments/message-headers/prov-headers.html"
|
|
>Provisional Message Header Field Names</a>).
|
|
</p>
|
|
</div>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>The <code>X-Device-</code> 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
|
|
<code>X-Device</code> header fields, which may happen where there are
|
|
multiple transforming proxies, is undefined (see <a href="#sec-scope-for-future-work"><span class="specref">K Scope for Future Work</span></a>).
|
|
</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-additional-headers" id="sec-additional-headers"></a>4.1.6 Additional HTTP Header Fields
|
|
</h4>
|
|
<p>Irrespective of the presence of a <code>no-transform</code> directive:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>proxies <strong id="ta-12437">should</strong> add the IP address of the initiator
|
|
of the request to the end of a comma separated list in an
|
|
<code>X-Forwarded-For</code> HTTP header field;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>proxies <strong id="ta-14351">must</strong> (in accordance with RFC
|
|
2616) include a <code>Via</code> HTTP
|
|
header field (see <a href="#sec-via-headers"><span class="specref">4.1.6.1 Proxy Treatment of Via Header Field</span></a>).
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-via-headers" id="sec-via-headers"></a>4.1.6.1 Proxy Treatment of <code>Via</code> Header Field
|
|
</h5>
|
|
<p>Proxies <strong id="ta-49612">should</strong> indicate their ability to transform content by including a comment in the <code>Via</code> HTTP
|
|
header field consisting of the URI "http://www.w3.org/ns/ct".
|
|
</p>
|
|
<p>When forwarding <code>Via</code> header fields, proxies <strong id="ta-41044">should
|
|
not</strong> alter them by removing comments from them.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>According to <a href="#ref-HTTP">[RFC 2616 HTTP]</a>
|
|
<a href="http://tools.ietf.org/html/rfc2616#section-14.45">Section 14.45</a>
|
|
<code>Via</code> header field comments "<strong>may</strong> 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.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-Proxy-Response" id="sec-Proxy-Response"></a>4.2 Proxy Forwarding of Response to User Agent
|
|
</h3>
|
|
<p>In the following, proxies <strong id="ta-32045">must</strong> check for the presence of equivalent <code><meta http-equiv></code> elements in HTML content, if the relevant HTTP header field is not present.
|
|
</p>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-administrative-arrangements" id="sec-administrative-arrangements"
|
|
></a>4.2.1 User Preferences
|
|
</h4>
|
|
<p>Proxies <strong id="ta-14363">must</strong> provide a means for users to express preferences for inhibiting content transformation even when content transformation has
|
|
been chosen by the user as the default behavior. Those preferences <strong id="ta-21589">must</strong> be maintained on a user by user and Web site by Web site basis.
|
|
</p>
|
|
<p>Proxies <strong id="ta-1707">must</strong> solicit re-expression of preferences in respect of a server if the server starts to indicate that it offers varying responses
|
|
as discussed under <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a>.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-receipt-of-cache-control-no-transform"
|
|
id="sec-receipt-of-cache-control-no-transform"
|
|
></a>4.2.2 Receipt of <code>Cache-Control: no-transform</code></h4>
|
|
<p>If the response includes a <code>Cache-Control: no-transform</code> directive
|
|
then proxies <strong id="ta-4894">must not</strong> alter it other than to comply with
|
|
<a title="transparent proxy" href="#term-transparent">transparent</a> HTTP behavior as described in <a href="#ref-HTTP">[RFC 2616 HTTP]</a> <a href="http://tools.ietf.org/html/rfc2616.html#section-13.5.2">Section 13.5.2</a> and <a href="http://tools.ietf.org/html/rfc2616.html#section-14.9.5">Section 14.9.5</a>.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-proxy-use-of-no-transform" id="sec-proxy-use-of-no-transform"
|
|
></a>4.2.3 Use of <code>Cache-Control: no-transform</code></h4>
|
|
<p>Proxies <strong>may</strong> use <code>Cache-Control: no-transform</code> to inhibit transformation by further proxies.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-unacceptable-response" id="sec-unacceptable-response"></a>4.2.4 Server Rejection of HTTP Request
|
|
</h4>
|
|
<p>Proxies <strong>may</strong>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-receipt-of-vary-header" id="sec-receipt-of-vary-header"></a>4.2.5 Receipt of <code>Vary</code> HTTP Header Field
|
|
</h4>
|
|
<p>A proxy may not be carrying out content tasting as described under <a href="#sec-avoiding-request-unacceptable"><span class="specref">4.1.5.2 Avoiding "Request Unacceptable" Responses</span></a> if it anticipates receiving a "request unacceptable" response. However, if it makes a request with altered header fields
|
|
in these circumstances, and receives a response
|
|
containing a <code>Vary</code> header field referring to one of the altered
|
|
header fields then it <strong id="ta-58567">should</strong> request the resource again with
|
|
unaltered header fields. It <strong id="ta-52209">should</strong> also update whatever heuristics
|
|
it uses so that unaltered header fields are presented first in subsequent requests
|
|
for this resource.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-receipt-of-link-to-handheld" id="sec-receipt-of-link-to-handheld"
|
|
></a>4.2.6 Link to "handheld" Representation
|
|
</h4>
|
|
<p>If the response is an HTML response and it contains a <code><link
|
|
rel="alternate" media="handheld" /></code> element (and the user agent is determined as being "handheld"), a proxy
|
|
<strong id="ta-43424">should</strong> request and process the referenced resource,
|
|
unless the resource referenced is the <a title="current representation" href="#term-current-representation">current representation</a>.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p><a name="term-current-representation" id="term-current-representation"
|
|
title="current representation"
|
|
></a>In this document the term <b>current representation</b> means a "same document reference" as defined in <a href="#ref-rfc-3986">[RFC 3986]</a> <a href="http://tools.ietf.org/html/rfc3986#section-4.4">Section 4.4</a>, with the addition that if a <code>Vary</code> 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.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-WML-content" id="sec-WML-content"></a>4.2.7 WML Content
|
|
</h4>
|
|
<p>If the content is WML proxies <strong id="ta-43472">should</strong> act in a <a title="transparent proxy" href="#term-transparent">transparent</a> manner.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>This does not affect the operation of proxies that are also WAP Gateways.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-proxy-decision-to-transform" id="sec-proxy-decision-to-transform"
|
|
></a>4.2.8 Proxy Decision to Transform
|
|
</h4>
|
|
<p>In the absence of a <code>Vary</code> or <code>no-transform</code> directive
|
|
(or a <code>meta HTTP-Equiv</code> element containing <code>Cache-Control:
|
|
no-transform</code>) proxies <strong id="ta-64788">should not</strong> transform content matching any of the following rules unless the user has specifically requested transformation:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>the content is HTML and contains <code><link rel="alternate" media="handheld"/></code> with a reference to the <a title="current representation" href="#term-current-representation">current representation</a>;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the <code>DOCTYPE</code> of the content (if it has one) indicates XHTML-MP, XHTML Basic, WML or iMode as listed in <a href="#sec-Mobile-DOCTYPES"><span class="specref">E DOCTYPEs Associated with Mobile Content</span></a>;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the <code>Content-Type</code> has a value listed in <a href="#sec-Mobile-Content-Types"><span class="specref">C Internet Content Types associated with Mobile Content</span></a>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the URI of the response (following redirection or as indicated by the
|
|
<code>Content-Location</code> HTTP header field) matches a pattern listed in <a href="#sec-Mobile-URI-Patterns"><span class="specref">F URI Patterns Associated with Mobile Web Sites</span></a>;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the response contains a resource that is referenced as an <a href="http://www.w3.org/TR/mobileOK-basic10-tests/#included_resources"
|
|
>included resource</a> suitable for "handheld" in a resource that was itself handled transparently;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the <code>Content-Type</code> indicates that the content is "data" - some values are listed in <a href="#sec-Data-Content-Types"><span class="specref">D Internet Content Types associated with Data Content</span></a>;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>a claim of mobileOK Basic <a href="#ref-mobileOK">[mobileOK Basic Tests]</a> conformance
|
|
is indicated (see <a href="#ref-mobileOK-scheme">[mobileOK Scheme]</a> for how such a claim may be indicated).
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<p>Other factors that a proxy <strong>may</strong> take into account:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>The Web site (see <a href="#term-web-site">note</a>) has previously shown that it is
|
|
contextually aware, even if the present response does not indicate
|
|
this;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the user agent has features (such as linearization or zoom, or is a desktop device using a mobile network for access) that
|
|
allow it to present the content unaltered;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the response contains client side scripts that may misoperate if the
|
|
resource is restructured;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>the response is an HTML response and it includes
|
|
<code><link></code> elements specifying
|
|
alternatives according to presentation media type.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-alteration-of-response" id="sec-alteration-of-response"></a>4.2.8.1 Alteration of Response
|
|
</h5>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>Other than as noted in this
|
|
section the nature of restructuring that is carried out, any character encoding alterations and what is
|
|
omitted and what is inserted is, as discussed in <a href="#sec-scope"><span class="specref">1.3 Scope</span></a>, out of scope of this document.
|
|
</p>
|
|
</div>
|
|
<p>If a proxy alters the response then:</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>It <strong id="ta-34526">must</strong> add a <code>Warning 214 Transformation
|
|
Applied</code> HTTP header field;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>The altered content <strong id="ta-55014">should</strong> validate according
|
|
to an appropriate published formal grammar and if XML <strong id="ta-10803">must</strong> be <a href="http://www.w3.org/TR/xml/#dt-wellformed">well-formed</a>;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>It <strong id="ta-39889">should</strong> indicate to the user that the
|
|
content has been transformed for mobile presentation and provide
|
|
an option to view the original, unmodified content.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-link-rewriting" id="sec-link-rewriting"></a>4.2.8.2 Link Rewriting
|
|
</h5>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p><a name="term-same-origin" id="term-same-origin" title="Same-Origin"></a>In this document two URIs have the <b>Same-Origin</b> if the <code>scheme</code> component and the <code>host</code> and <code>port</code> subcomponents, as defined in <a href="#ref-rfc-3986">[RFC 3986]</a>, all match. <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a> of <a href="#ref-rfc-3986">[RFC 3986]</a> discusses URI comparison.
|
|
</p>
|
|
</div>
|
|
<p>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 <a title="Same-Origin" href="#term-same-origin">same-origin</a> and hence there is a danger of introducing security vulnerabilities.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>This section (on link rewriting) refers also to insertion of links, frame flattening and any other techniques that introduces
|
|
the "same-origin" issue.
|
|
</p>
|
|
</div>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>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.
|
|
</p>
|
|
</div>
|
|
<p>Proxies <strong id="ta-5078">must not</strong> rewrite links when content transformation is prohibited.
|
|
</p>
|
|
<p>Proxies <strong id="ta-18105">must</strong> preserve security between requests for domains that are not <a title="Same-Origin" href="#term-same-origin">same-origin</a> in respect of cookies and scripts.
|
|
</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-https-link-rewriting" id="sec-https-link-rewriting"></a>4.2.8.3 HTTPS Link Rewriting
|
|
</h5>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>For clarity it is emphasized that it is not possible for a
|
|
transforming proxy to transform content accessed via an HTTPS link
|
|
without breaking end-to-end security.
|
|
</p>
|
|
<p>Interception of HTTPS and the circumstances in which it 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 time of writing of this document.
|
|
</p>
|
|
</div>
|
|
<p>The practice of intercepting HTTPS links is strongly <strong id="ta-43818">NOT RECOMMENDED</strong>.
|
|
</p>
|
|
<p>If a proxy rewrites HTTPS links, it
|
|
<strong id="ta-26858">must</strong> advise the user of the security implications
|
|
of doing so and <strong id="ta-17637">must</strong> provide the option to bypass it and to communicate with the server directly.
|
|
</p>
|
|
<p>Notwithstanding anything else in this document, proxies <strong id="ta-53227">must not</strong> rewrite HTTPS links in the presence of a <code>Cache-Control: no-transform</code> directive.
|
|
</p>
|
|
<p>If a proxy rewrites HTTPS links, replacement links
|
|
<strong id="ta-36041">must</strong> have the scheme <code>https</code>.
|
|
</p>
|
|
<p>When forwarding requests originating from HTTPS links proxies <strong id="ta-40493">must</strong> include a <code>Via</code> header field as discussed under <a href="#sec-via-headers"><span class="specref">4.1.6.1 Proxy Treatment of Via Header Field</span></a>.
|
|
</p>
|
|
<p>When forwarding responses from servers proxies <strong id="ta-10117">must</strong> notify the user of invalid server certificates.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-testing" id="sec-testing"></a>5 Testing (Normative)</h2>
|
|
<p>Operators of content transformation proxies <strong id="ta-58462">should</strong>
|
|
make available an interface through which the functions of
|
|
the proxy can be exercised. The operations possible
|
|
through this interface <strong id="ta-4172">must</strong> cover those necessary to
|
|
settle the outcome of all conformance statements listed in
|
|
section B.
|
|
</p>
|
|
<p>The interface <strong id="ta-23958">must</strong> 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 <strong>may</strong> necessitate
|
|
adjusting standard Web browsing configuration
|
|
parameters -- such as specifying a proxy IP address and
|
|
port on a desktop browser, or activating a WAP setting on
|
|
a mobile browser.
|
|
</p>
|
|
<p>Such access <strong id="ta-1181">must</strong> be granted under fair, reasonable and non-discriminatory conditions. In
|
|
particular:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>it is available to all, worldwide, whether or not they are W3C Members;</p>
|
|
</li>
|
|
<li>
|
|
<p>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 the interface, disclaimer of liability.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="back">
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-references" id="sec-references"></a>A References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="ref-CT-Landscape" id="ref-CT-Landscape"></a>CT Landscape
|
|
</dt>
|
|
<dd>Content
|
|
Transformation Landscape 1.0, Jo Rabin, Andrew Swainston (eds), W3C Working
|
|
Group Note 27 October 2009 (See <a href="http://www.w3.org/TR/2009/NOTE-ct-landscape-20091027/">http://www.w3.org/TR/2009/NOTE-ct-landscape-20091027/</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-rfc-2119" id="ref-rfc-2119"></a>RFC 2119
|
|
</dt>
|
|
<dd>Key words for use in RFCs to Indicate
|
|
Requirement Levels, , Request for Comments: 2119, S. Bradner, March 1997 (See <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-HTTP" id="ref-HTTP"></a>RFC 2616 HTTP
|
|
</dt>
|
|
<dd> Hypertext Transfer Protocol --
|
|
HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H.
|
|
Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See <a href="http://tools.ietf.org/html/rfc2616">http://tools.ietf.org/html/rfc2616</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-rfc-3986" id="ref-rfc-3986"></a>RFC 3986
|
|
</dt>
|
|
<dd>Uniform Resource Identifier (URI):
|
|
Generic Syntax, Request for Comments: 3986, T. Berners-Lee, R. Fielding, L.
|
|
Masinter, January 2005 (See <a href="http://tools.ietf.org/html/rfc3986">http://tools.ietf.org/html/rfc3986</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-OPES" id="ref-OPES"></a>RFC 3238 OPES
|
|
</dt>
|
|
<dd>
|
|
IAB Architectural and Policy Considerations for Open Pluggable Edge Services, Request for Comments: 3238,
|
|
S. Floyd, L. Daigle, January 2002 (See <a href="http://tools.ietf.org/html/rfc3238">http://tools.ietf.org/html/rfc3238</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-DIGLOSS" id="ref-DIGLOSS"></a>Device Independence Glossary
|
|
</dt>
|
|
<dd>W3C Glossary of Terms for Device Independence, Rhys Lewis
|
|
(ed), W3C Working Draft 18 January 2005
|
|
</dd>
|
|
<dt class="label"><a name="ref-BestPractices" id="ref-BestPractices"></a>Best Practices
|
|
</dt>
|
|
<dd>Mobile Web Best
|
|
Practices 1.0 Basic Guidelines, Jo Rabin, Charles McCathieNevile (eds), W3C
|
|
Recommendation, 29 July 2008 (See <a href="http://www.w3.org/TR/2008/REC-mobile-bp-20080729/">http://www.w3.org/TR/2008/REC-mobile-bp-20080729/</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-mobileOK" id="ref-mobileOK"></a>mobileOK Basic Tests
|
|
</dt>
|
|
<dd>W3C mobileOK
|
|
Basic Tests 1.0, Sean Owen, Jo Rabin (eds), W3C Recommendation, 08 December 2008 (See <a href="http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/"
|
|
>http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-mobileOK-scheme" id="ref-mobileOK-scheme"></a>mobileOK Scheme
|
|
</dt>
|
|
<dd>W3C mobileOK
|
|
Scheme 1.0, Jo Rabin, Phil Archer (eds), W3C Note, 25 August 2009 (See <a href="http://www.w3.org/TR/2009/NOTE-mobileOK-20090825/">http://www.w3.org/TR/2009/NOTE-mobileOK-20090825/</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-powder-grouping" id="ref-powder-grouping"></a>POWDER Resource Grouping
|
|
</dt>
|
|
<dd>Protocol for Web Description Resources (POWDER): Grouping of Resources, Phil Archer, Andrea Perego, Kevin Smith (eds), W3C
|
|
Recommendation, 1 September 2009 (See <a href="http://www.w3.org/TR/2009/REC-powder-grouping-20090901/">http://www.w3.org/TR/2009/REC-powder-grouping-20090901/</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-XHR" id="ref-XHR"></a>XHR
|
|
</dt>
|
|
<dd>XMLHttpRequest, Anne van
|
|
Kesteren (ed), W3C Candidate Recommendation 3 August 2010 (See <a href="http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/">http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/</a>)
|
|
</dd>
|
|
<dt class="label"><a name="ref-XML" id="ref-XML"></a>XML
|
|
</dt>
|
|
<dd>Extensible Markup Language (XML) 1.0 (Fifth Edition), T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, F. Yergeau (eds),
|
|
W3C Recommendation, 26 November 2008. (See <a href="http://www.w3.org/TR/2008/REC-xml-20081126/">http://www.w3.org/TR/2008/REC-xml-20081126/</a>)
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-ConformanceStatement" id="sec-ConformanceStatement"></a>B Conformance Statement</h2>
|
|
<p>See <a href="http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/ics">http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/ics</a>
|
|
</p>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-Mobile-Content-Types" id="sec-Mobile-Content-Types"></a>C Internet Content Types associated with Mobile Content</h2>
|
|
<p>This list is not exhaustive and is likely to change.</p>
|
|
<div class="exampleInner"><pre>application/vnd.wap.xhtml+xml</pre></div>
|
|
<div class="exampleInner"><pre>text/vnd.wap.wml</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.wmlc</pre></div>
|
|
<div class="exampleInner"><pre>text/vnd.wap.wml+xml</pre></div>
|
|
<div class="exampleInner"><pre>text/vnd.wap.wmlscript</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.wmlscriptc</pre></div>
|
|
<div class="exampleInner"><pre>image/vnd.wap.wbmp</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.wbxml</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.multipart.mixed</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.multipart.related</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.multipart.alternative</pre></div>
|
|
<div class="exampleInner"><pre>application/vnd.wap.multipart.form-data</pre></div>
|
|
<div class="exampleInner"><pre>image/x-up-wpng</pre></div>
|
|
<div class="exampleInner"><pre>image/x-up-bmp</pre></div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-Data-Content-Types" id="sec-Data-Content-Types"></a>D Internet Content Types associated with Data Content</h2>
|
|
<p>This list is not exhaustive and is likely to change.</p>
|
|
<div class="exampleInner"><pre>application/json</pre></div>
|
|
<div class="exampleInner"><pre>application/soap+xml</pre></div>
|
|
<div class="exampleInner"><pre>application/soap+fastinfoset</pre></div>
|
|
<div class="exampleInner"><pre>application/fastsoap</pre></div>
|
|
<div class="exampleInner"><pre>application/fastinfoset</pre></div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-Mobile-DOCTYPES" id="sec-Mobile-DOCTYPES"></a>E DOCTYPEs Associated with Mobile Content</h2>
|
|
<p>This list is not exhaustive and is likely to change.</p>
|
|
<div class="exampleInner"><pre>-//OMA//DTD XHTML Mobile 1.2//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD XHTML Mobile 1.1//EN </pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD XHTML Mobile 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//W3C//DTD XHTML Basic 1.1//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//W3C//DTD XHTML Basic 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//OPENWAVE//DTD XHTML 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//OPENWAVE//DTD XHTML Mobile 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.0) 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.1) 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.0) 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.1) 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.2) 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.3) 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//W3C//DTD Compact HTML 1.0 Draft//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//BBSW//DTD Compact HTML 2.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.1//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.2//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.3//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//WAPFORUM//DTD WML 2.0//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//PHONE.COM//DTD WML 1.1//EN</pre></div>
|
|
<div class="exampleInner"><pre>-//OPENWAVE.COM//DTD WML 1.3//EN</pre></div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-Mobile-URI-Patterns" id="sec-Mobile-URI-Patterns"></a>F URI Patterns Associated with Mobile Web Sites</h2>
|
|
<p>Using the notation defined in <a href="#ref-powder-grouping">[POWDER Resource Grouping]</a>:
|
|
</p>
|
|
<div class="exampleInner"><pre><iriset>
|
|
<includehosts>mobi</includehosts>
|
|
</iriset></pre></div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-Summary-User-Preference-Handling" id="sec-Summary-User-Preference-Handling"></a>G Summary of User Preference Handling</h2>
|
|
<p>User expression of preferences is referred to in several sections in this document. Those sections are:</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p><a href="#sec-priority-of-intention"><span class="specref">1.4.2 Priority of Intention</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-serving-cached-responses"><span class="specref">4.1.4 Serving Cached Responses</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-user-selection"><span class="specref">4.1.5.3 User Selection of Restructured Experience</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-administrative-arrangements"><span class="specref">4.2.1 User Preferences</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-receipt-of-cache-control-no-transform"><span class="specref">4.2.2 Receipt of Cache-Control: no-transform</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-proxy-decision-to-transform"><span class="specref">4.2.8 Proxy Decision to Transform</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-alteration-of-response"><span class="specref">4.2.8.1 Alteration of Response</span></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#sec-https-link-rewriting"><span class="specref">4.2.8.3 HTTPS Link Rewriting</span></a></p>
|
|
</li>
|
|
</ol>
|
|
<p>User preferences are also referred to non-normatively under <a href="#sec-varying-representations"><span class="specref">I.1.4 Varying Representations</span></a>.
|
|
</p>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-example-transformation-interactions" id="sec-example-transformation-interactions"></a>H Example Transformation Interactions (Non-Normative)</h2>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>The following examples refer to requests with the GET method.</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-basic-content-tasting" id="sec-basic-content-tasting"></a>H.1 Basic Content Tasting by Proxy
|
|
</h3>
|
|
<div class="exampleOuter">
|
|
<p class="flow1">Request resource with original header fields</p>
|
|
<p class="flow1">If the response is a 406 response:</p>
|
|
<p class="flow2">If the response contains <code>Cache-Control:
|
|
no-transform</code>, forward it
|
|
</p>
|
|
<p class="flow2">Otherwise request again with altered header fields</p>
|
|
<p class="flow1">If the response is a 200 response:</p>
|
|
<p class="flow2">If the response contains <code>Vary: User-Agent</code>, an
|
|
appropriate <code>link</code> element or header field, or <code>Cache-Control:
|
|
no-transform</code>, forward it
|
|
</p>
|
|
<p class="flow2">Otherwise assess whether the 200 response is a form of "Request
|
|
Unacceptable"
|
|
</p>
|
|
<p class="flow3">If it is not, forward it</p>
|
|
<p class="flow3">If it is, request again with altered header fields</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-proxy-a-priori-knowledge" id="sec-proxy-a-priori-knowledge"
|
|
></a>H.2 Optimization based on Previous Server Interaction
|
|
</h3>
|
|
<div class="exampleOuter">
|
|
<p class="flow1">Proxy receives a request for resource P that it has not
|
|
encountered before
|
|
</p>
|
|
<p class="flow1">Proxy forwards this request</p>
|
|
<p class="flow1">Response is 200 OK containing the text "Unsupported browser.
|
|
Please get a different one or use a CT proxy."
|
|
</p>
|
|
<p class="flow1">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)
|
|
</p>
|
|
<p class="flow1">Response is a desktop oriented representation of the resource</p>
|
|
<p class="flow1">Proxy transforms this response into content that the user agent
|
|
can display well and forwards it
|
|
</p>
|
|
<p class="flow1">Proxy receives a further request for the resource P</p>
|
|
<p class="flow1">Based on evidence from the previous interaction (e.g. that there
|
|
was no <code>Vary</code> header field, that the response was not targeted at only
|
|
the previous user in that there was no <code>Cache-Control: private</code>
|
|
directive) the CT proxy forwards the request with altered header fields
|
|
</p>
|
|
<p class="flow1">Response is a desktop oriented representation of the resource</p>
|
|
<p class="flow1">Proxy transforms this response into content that the user agent
|
|
can display well and forwards it
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-optimization-previous-interaction" id="sec-optimization-previous-interaction"></a>H.3 Optimization based on Previous Server Interaction, Server has Changed its
|
|
Operation
|
|
</h3>
|
|
<div class="exampleOuter">
|
|
<p class="flow1">Proxy receives a request for resource P, that it has previously
|
|
encountered as in <a href="#sec-proxy-a-priori-knowledge"><span class="specref">H.2 Optimization based on Previous Server Interaction</span></a></p>
|
|
<p class="flow1">Proxy forwards request with altered header fields</p>
|
|
<p class="flow1">Response is 200 OK containing a <code>Vary: User-Agent</code>
|
|
header field
|
|
</p>
|
|
<p class="flow1">Proxy notices that behavior has changed and reissues the request
|
|
with original header fields
|
|
</p>
|
|
<p class="flow1">Response is 200 OK and proxy forwards it</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-representation-intended" id="sec-representation-intended"></a>H.4 Server Response Indicating that this Representation is Intended for the Target
|
|
Device
|
|
</h3>
|
|
<div class="exampleOuter">
|
|
<p class="flow1">Proxy receives a request for resource P</p>
|
|
<p class="flow1">Proxy forwards request with original header fields</p>
|
|
<p class="flow1">Response is 200 OK with <code>Vary: User-Agent</code> and
|
|
<code><link type="alternate" media="handheld" href="P#id"
|
|
/></code> where id is a document local reference
|
|
</p>
|
|
<p class="flow1">Proxy forwards response as designed specifically for the
|
|
requesting device
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-another-representation" id="sec-another-representation"></a>H.5 Server Response Indicating that another Representation is Intended for the Target Device</h3>
|
|
<div class="exampleOuter">
|
|
<p class="flow1">Proxy receives a request for resource P</p>
|
|
<p class="flow1">Proxy forwards request with original header fields</p>
|
|
<p class="flow1">Response is 200 OK with <code><link type="alternate"
|
|
media="handheld" href="Q" /></code> and Q is not P
|
|
</p>
|
|
<p class="flow1">Proxy requests Q with original header fields</p>
|
|
<p class="flow1">Response is 200 OK and proxy forwards it</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-guidance-origin-servers" id="sec-guidance-origin-servers"></a>I Informative Guidance for Origin Servers (Non-Normative)</h2>
|
|
<p>Content providers may wish to follow these procedures in order to improve interoperability.</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-ServerResponse" id="sec-ServerResponse"></a>I.1 Server Response to Proxy
|
|
</h3>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-server-use-of-406" id="sec-server-use-of-406"></a>I.1.1 Use of HTTP 406 Status
|
|
</h4>
|
|
<p>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.
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-server-use-of-403" id="sec-server-use-of-403"></a>I.1.2 Use of HTTP 403 Status
|
|
</h4>
|
|
<p>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 <code>Via</code> HTTP header field in an HTTPS request).
|
|
</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-cache-control-no-transform" id="sec-cache-control-no-transform"
|
|
></a>I.1.3 Server Origination of <code>Cache-Control: no-transform</code></h4>
|
|
<p>Servers should consider including a <code>Cache-Control:
|
|
no-transform</code> 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.
|
|
</p>
|
|
<p>Include a <code>Cache-Control:
|
|
no-transform</code> directive if, for any reason,
|
|
transformation of the response is prohibited.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p id="wml-no-transform-note">Including a <code>Cache-Control:
|
|
no-transform</code> directive can disrupt the behavior of WAP Gateways,
|
|
because it can inhibit such proxies from converting WML to
|
|
WMLC.
|
|
</p>
|
|
<p>Including such a directive may also disrupt the behavior of a proxy based accessibility solution.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec-varying-representations" id="sec-varying-representations"
|
|
></a>I.1.4 Varying Representations
|
|
</h4>
|
|
<p>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.
|
|
</p>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-use-of-vary-header" id="sec-use-of-vary-header"></a>I.1.4.1 Use of <code>Vary</code> HTTP Header Field
|
|
</h5>
|
|
<p>If a server varies its representation according to examination of
|
|
received HTTP header fields then <a href="#ref-HTTP">[RFC 2616 HTTP]</a> describes how to use the <code>Vary</code> header field to indicate this.
|
|
</p>
|
|
<p>Servers that are aware of the presence of a transforming proxy, as identified by a
|
|
<code>Via</code> 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 <code>Content-Type: application/vnd.wap.xhtml+xml</code>
|
|
because it suspects that proxies will not transform
|
|
content of this type, if its content is not valid XHTML-MP).
|
|
</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="sec-use-of-link-element" id="sec-use-of-link-element"></a>I.1.4.2 Indication of Intended Presentation Media Type of Representation
|
|
</h5>
|
|
<p>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 <code>Cache-Control:
|
|
no-transform</code> directive (see <a href="#sec-cache-control-no-transform"><span class="specref">I.1.3 Server Origination of Cache-Control: no-transform</span></a>).
|
|
</p>
|
|
<p>In addition, in HTML content it can indicate the medium for
|
|
which the representation is intended by including a <code>link</code>
|
|
element identifying in its <code>media</code> attribute the target
|
|
presentation media types of this representation and setting the
|
|
<code>href</code> attribute to "Same-Document Reference" (see <a href="#ref-rfc-3986">[RFC 3986]</a> <a href="http://tools.ietf.org/html/rfc3986.html#section-4.4">section 4.4</a>) and in particular an empty <code>href</code> attribute is a "Same Document Reference".
|
|
</p>
|
|
<p>In addition it is good practice to include <code>link</code>
|
|
elements identifying the target presentation media types of other
|
|
available representations in a similar manner.
|
|
</p>
|
|
<p>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 <code>Vary</code> HTTP header field indicating that the response varies according to the received <code>User-Agent</code> HTTP header field.
|
|
</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>Some examples of the use of the <code>link</code> element are
|
|
included above in <a href="#sec-example-transformation-interactions"><span class="specref">H Example Transformation Interactions</span></a>.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-applicability" id="sec-applicability"></a>J Applicability to Transforming Solutions which are Out of Scope (Non-Normative)</h2>
|
|
<p>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.
|
|
</p>
|
|
<p>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.
|
|
</p>
|
|
<p>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.
|
|
</p>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-scope-for-future-work" id="sec-scope-for-future-work"></a>K Scope for Future Work (Non-Normative)</h2>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-powder" id="sec-powder"></a>K.1 POWDER
|
|
</h3>
|
|
<p>The BPWG believes that <a href="http://www.w3.org/2007/powder/">POWDER</a>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-link-http-header" id="sec-link-http-header"></a>K.2 <code>link</code> HTTP Header Field
|
|
</h3>
|
|
<p>The BPWG believes that the <code>link</code> HTTP header field which was removed from
|
|
HTTP/1.1, and which is under discussion for reintroduction, would
|
|
represent a more general and flexible mechanism than use of the HTML
|
|
<code>link</code> element, as discussed in this recommendation.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-sources-devinfo" id="sec-sources-devinfo"></a>K.3 Sources of Device Information
|
|
</h3>
|
|
<p>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.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-inter-proxy-comm" id="sec-inter-proxy-comm"></a>K.4 Inter Proxy Communication
|
|
</h3>
|
|
<p>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.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-explicit-consent" id="sec-explicit-consent"></a>K.5 Explicit Consent
|
|
</h3>
|
|
<p>Robust mechanisms are needed for indicating consent to or prohibition of transformation operations of various kinds, especially
|
|
HTTPS link rewriting (see <a href="#sec-https-link-rewriting"><span class="specref">4.2.8.3 HTTPS Link Rewriting</span></a>).
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="sec-amendment-http" id="sec-amendment-http"></a>K.6 Amendment to and Refinement of HTTP
|
|
</h3>
|
|
<p>The 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).
|
|
</p>
|
|
<p>At present HTTP does not provide a mechanism for communicating original header field
|
|
values. The scheme based on X-Device
|
|
prefixed fields described under <a href="#sec-altering-header-values"><span class="specref">4.1.5 Alteration of HTTP Header Field Values</span></a> records
|
|
and clarifies an approach used to achieve this effect by some content
|
|
transformation proxies. This scheme relies upon non-standard HTTP header fields which have been provisionally registered with
|
|
IANA. 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.
|
|
</p>
|
|
<p>A number of mechanisms exist in HTTP which might be exploited given more precise
|
|
definition of their operation - for example the <code>OPTIONS</code> method and
|
|
the HTTP 300 (Multiple Choices) Status.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="sec-acknowledgements" id="sec-acknowledgements"></a>L Acknowledgments (Non-Normative)</h2>
|
|
<p>The editor acknowledges contributions of various kinds from members of the <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> and earlier from the
|
|
<a href="http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/">Content Transformation Task Force</a> of that group.
|
|
</p>
|
|
<p>The editor acknowledges significant written contributions from:</p>
|
|
<ul>
|
|
<li>François Daoust (Task Force Leader), W3C</li>
|
|
<li>Magnus Lönnroth, Ericsson (and previously at Drutt)</li>
|
|
<li>Bryan Sullivan, AT&T</li>
|
|
<li>Sean Patterson, Novarra</li>
|
|
<li>Aaron Kemp, Google</li>
|
|
<li>Rob Finean, Openwave</li>
|
|
<li>Heiko Gerlach, Vodafone</li>
|
|
<li>Martin Jones, Volantis</li>
|
|
<li>Tom Hume, W3C Invited Expert</li>
|
|
<li>Eduardo Casais, W3C Invited Expert</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|