Guidelines for Web Content Transformation Guidelines 1o (Rev 15) Proxies 1u

W3C Editor's Draft 30 July 2008 23 September 2009

This version:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080730 http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090923
Latest version:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/latest
Previous versions:
Draft 1t 21 Sept 2009 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090921
Draft 1s - 22 June 2009 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090622
Draft 1r - 7 June 2009 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090607
Draft 1q - 13 March 2009 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313
Draft 1p - 7 Nov 2008 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107
Draft 1o - 30 July 2008 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080730
Draft 1n - 24 July 2008 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080724
Draft 1m - 22 July 2008 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080722
Draft 1l - 12 July 2008 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080712
Draft 1k - 6 June 2008 ( diff ) http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606
Editor:
Jo Rabin, mTLD Top Level Domain (dotMobi)

Abstract

This document provides guidance to content transformation Content Transformation proxies and content providers as to whether and how inter-work when delivering to transform Web content.

Content Transformation proxies alter requests sent by user agents to servers and responses returned by servers so that the appearance, structure or control flow of Web applications are modified. Content Transformation proxies are mostly used to convert Web sites designed for desktop computers to a form suitable for mobile devices.

Based on current practice and standards, this document specifies mechanisms with which Content Transformation proxies should make their presence known to other parties, present the outcome of alterations performed on HTTP traffic, and react to indications set by clients or servers to constrain these alterations.

The objective is to reduce undesirable effects on Web applications, especially mobile-ready ones, and to limit the diversity in the modes of operation of Content Transformation proxies, while at the same time allowing proxies to alter content that would otherwise not display successfully on mobile devices.

Important considerations regarding the impact on security are highlighted.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/ .

This document reflects group resolutions on comments received on the previous Last Call Working Draft .

Publication as a Group Working Draft of a proposed normative Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the Content Transformation Task Force of the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . Please send comments on this document to the Working Group's public email list public-bpwg-ct@w3.org , a publicly archived mailing list .

This document was produced under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy .

Revision Description

Table of Contents

1 Introduction (Non-Normative)
    1.1 Purpose
    1.2 Audience
    1.3 Scope
    1.4 Summary Principles
        1.4.1 IAB Considerations
        1.4.2 Priority of Requirements Intention
2 Terminology (Normative)
    2.1 Types of Proxy
    2.2 Types of Transformation
3 Conformance (Normative)
    3.1 Classes of Product
    3.2 Normative and Informative Parts
    3.3 Normative Language for Conformance Requirements
    3.4 Content Deployment Conformance     3.5 Transformation Deployment Conformance
4 Behavior of Components (Normative)
    4.1 Proxy Forwarding of Request
        4.1.1 Applicable HTTP Methods
        4.1.2 no-transform directive in Request
        4.1.3 Treatment of Requesters that are not Web browsers
        4.1.4 Serving Cached Responses
        4.1.5 Alteration of HTTP Header Field Values
            4.1.5.1 Content Tasting
            4.1.5.2 Avoiding "Request Unacceptable" Responses
            4.1.5.3 User Selection of Restructured Experience
            4.1.5.4 Sequence of Requests
            4.1.5.5 Original Headers Header Fields
        4.1.6 Additional HTTP Headers Header Fields
            4.1.6.1 Proxy Treatment of Via Header Field
    4.2 Server Proxy Forwarding of Response to Proxy User Agent
        4.2.1 Use of HTTP 406 Status Applicable Responses
        4.2.2 Server Origination of Cache-Control: no-transform         4.2.3 Varying Representations             4.2.3.1 Use of Vary HTTP Header             4.2.3.2 Indication of Intended Presentation Media Type of Representation     4.3 Proxy Forwarding of Response to User Agent Preferences
        4.3.1         4.2.3 Receipt of Cache-Control: no-transform
        4.3.2 Receipt         4.2.4 Use of Warning: 214 Transformation Applied Cache-Control: no-transform
        4.3.3         4.2.5 Server Rejection of HTTP Request
        4.3.4         4.2.6 Receipt of Vary HTTP Header Field
        4.3.5         4.2.7 Link to "handheld" Representation
        4.3.6         4.2.8 WML Content
        4.2.9 Proxy Decision to Transform
            4.3.6.1             4.2.9.1 Alteration of Response
            4.3.6.2             4.2.9.2 Link Rewriting
            4.2.9.3 HTTPS Link Re-writing Rewriting
5 Testing (Normative)

Appendices

A References
B Conformance Statement
C Internet Content Types associated with Mobile Content
D DOCTYPEs Associated with Mobile Content
E URI Patterns Associated with Mobile Web Sites
F Summary of User Preference Handling
G Example Transformation Interactions (Non-Normative)
    B.1     G.1 Basic Content Tasting by Proxy
    B.2     G.2 Optimization based on Previous Server Interaction
    B.3     G.3 Optimization based on Previous Server Interaction, Server has Changed its Operation
    B.4     G.4 Server Response Indicating that this Representation is Intended for the Target Device
    B.5     G.5 Server Response Indicating that another Representation is Intended for the Target Device
C H Informative Guidance for Origin Servers (Non-Normative)
    H.1 Server Response to Proxy
        H.1.1 Use of HTTP 406 Status
        H.1.2 Use of HTTP 403 Status
        H.1.3 Server Origination of Cache-Control: no-transform
        H.1.4 Varying Representations
            H.1.4.1 Use of Vary HTTP Header Field
            H.1.4.2 Indication of Intended Presentation Media Type of Representation
I Applicability to Transforming Solutions which are Out of Scope (Non-Normative)
D J Scope for Future Work (Non-Normative)
    D.1     J.1 POWDER
    D.2     J.2 link HTTP Header Field
    D.3     J.3 Sources of Device Information
    D.4     J.4 Inter Proxy Communication
    D.5     J.5 Amendment to and Refinement of HTTP
E Administrative Arrangements (Non-Normative) F K Acknowledgments (Non-Normative)


1 Introduction (Non-Normative)

1.1 Purpose

From the point of view of Within this document, document Content Transformation is refers to the manipulation in various ways, by proxies, of requests made to to, and content delivered by responses from, an origin server with a view server. This manipulation is carried out by proxies in order to provide a better user experience of content that would otherwise result in an unsatisfactory experience on the device making it more suitable for mobile presentation. the request.

The W3C Mobile Web Best Practices Working Group neither approves nor disapproves of Content Transformation, but recognizes that is being deployed widely across mobile data access networks. The deployments are widely divergent to each other, with many non-standard HTTP implications, and no well-understood means either of identifying the presence of such transforming proxies, nor of controlling their actions. This document establishes a framework to allow that to happen.

The overall objective of this document is to provide a means, as far as is practical, for users to be provided with at least a "functional user experience" [Device Independence Glossary] of the Web, when mobile, taking into account the fact that an increasing number of content providers create experiences specially tailored to the mobile context which they do not wish to be altered by third parties. Equally it takes into account the fact that there remain a very large number of Web sites that do not provide a functional user experience when perceived on many mobile devices.

1.3 Scope

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.

The BPWG W3C Mobile Web Best Practices Working Group (BPWG) is not chartered to create new technology - its role is to advise on best practice for use of existing technology. In satisfying Content Transformation requirements, existing HTTP headers, header fields, directives and behaviors must be respected, and as far as is practical, no extensions to [RFC 2616 HTTP] are to be used. 1.4 Summary of Requirements

This section summarizes the communication requirements The recommendations in this document refer to interactions of actors (users, user agents, transforming proxies a proxy and origin servers) do not refer to communicate with each other. It is recognised that several transformation proxies may be present but their interactions are any presumed aspects of the internal operation of the proxy. For this reason, the document does not discussed in detail. The relevant scenario discuss use of "allow" and "disallow" lists (though it does discuss behavior that is as follows: The needs induced by the implementation of these actors are as follows: The user agent needs to be able to tell 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 Content Transformation proxy insertion or insertion of headers and footers or any other specific behaviors (though it does discuss the origin server: need for essential user interaction of some form).

what type of mobile device and which user agent is being used; 1.4 Principles

that all Content Transformation should be avoided.

The Content Transformation proxy needs to be able to tell the origin server: 1.4.1 IAB Considerations

that some degree of Content Transformation ( The BPWG made reference to Internet Architecture Board (IAB) work on "Open Pluggable Edge Services" restructuring and recoding [RFC 3238 OPES] ) can be performed; for various principles that content is being requested on behalf underlie behavior of something else and what that something else is; that proxies. In this work the request headers have been altered IAB expressed its concerns about privacy, control, monitoring, and what the original ones were. accountability of such services.

The origin server needs to be able to tell the Content Transformation proxy: 1.4.2 Priority of Intention

that it varies The Web allows users considerable flexibility in respect of the representation of its responses according to device type and other factors; that it is not permissible to perform Content Transformation; that it has media-specific representations; that is unable or unwilling to deal with content. At the request in its present form. The same time, Content Transformation proxy needs Providers may have a preferred manner in which they wish their content to be able to tell represented. Content Transformation must reconcile these contrasting factors. In creating this Recommendation the user agent: that it BPWG has applied transformations of various kinds to the content. The determined that Content Transformation proxy needs to be able to interact with the user: to proxies should respect Content Providers intentions, where they are expressed, but may allow the user users to disable its features; choose other representations, except where Content Providers specifically prohibit this.

to alert the user to the fact The BPWG recognizes that it has transformed content and to allow access to an untransformed representation there is neither a systematic vocabulary for Content Provider Intentions, nor a systematic means of the content. Note: A more extensive discussion expression of the requirements such intentions. There is scope for these guidelines can be found further work in "Content Transformation Landscape" [CT Landscape] . this area (see J Scope for Future Work ).

2 Terminology (Normative)

2.2 Types of Transformation

Transforming proxies can carry out a wide variety of operations. In this document we categorize these operations as follows:

  1. Alteration of Requests

    Transforming proxies process requests in a number of ways, especially replacement of various request headers header fields to avoid HTTP 406 Status responses (if a server can not provide content that is compatible with the original HTTP request headers) header fields) and at user request.

  2. Alteration of Responses

    There are three classes of operation on responses:

    1. Restructuring content

      Restructuring content is a process whereby the original layout is altered so that content is added or removed or where the spatial or navigational relationship of parts of content is altered, e.g. by linearization (i.e. reordering presentation elements, especially tables, so that they fit on a narrow display and can be traversed without horizontal scrolling) or pagination. pagination (i.e. splitting a document too large to be stored in or transmitted to the terminal in one piece, so that it can be nevertheless accessed by browsing through a succession of smaller interlinked documents). It includes also includes rewriting of URIs so that subsequent requests route are routed via the proxy handling this the response.

    2. Recoding content

      Recoding content is a process whereby the layout of the content remains the same, but details of its encoding may be altered. Examples include re-encoding HTML as XHTML, correcting invalid markup in HTML, conversion of images between formats (but not, for example, reducing animations to static images).

    3. Optimizing content

      Optimizing content includes removing redundant white space, re-compressing images (without loss of fidelity) and compressing for transfer.

3 Conformance (Normative)

3.4 Content Deployment Conformance A Content Deployment conforms to these guidelines if it follows the statements in 4.2 Server Response to Proxy . 3.5 3.4 Transformation Deployment Conformance

A Transformation Deployment conforms to these guidelines if it follows the statements in 4.1 Proxy Forwarding of Request , 4.3 4.2 Proxy Forwarding of Response to User Agent and 5 Testing (Normative) .

A Transformation Deployment that wishes to claim conformance must make available a conformance statement B Conformance Statement that specifies the reasons for non-compliance with any clauses containing the key words should and should not , recommended and not recommended .

Conformance statements must be sent to public-content-transformation-conformance@w3.org . Public archives of this list may be found at http://lists.w3.org/Archives/Public/public-content-transformation-conformance/ .

4 Behavior of Components (Normative)

4.1 Proxy Forwarding of Request

4.1.2 no-transform directive in Request

If the request contains a Cache-Control: no-transform directive directive, proxies must not forward alter the request unaltered to the server, other than to comply with transparent HTTP behavior defined in [RFC 2616 HTTP] sections section 14.9.5 and section 13.5.2 and to add header fields as noted below (see described in 4.1.6 Additional HTTP Headers Header Fields ). below.

Note:

An example of the use of Cache-Control: no-transform is the issuing of asynchronous HTTP requests, perhaps by means of XMLHTTPRequest XMLHttpRequest [XHR] , which may include such a directive in order to prevent transformation of both the request and the response.

4.1.4 Serving Cached Responses

Proxies should follow standard HTTP procedures in respect of Aside from the usual caching and should use cached copies of resources where this is procedures defined in accordance with those procedures. In [RFC 2616 HTTP] , in some circumstances, proxies may paginate responses and where this is the case a request may be for a subsequent page of a previously requested resource. In this case proxies may for the sake of consistency of representation serve stale data but when doing so should notify the user that this is the case and should must provide a simple means of retrieving a fresh copy.

4.1.5 Alteration of HTTP Header Field Values

Aside from the usual procedures defined in [RFC 2616 HTTP] proxies should not modify the values of header fields other than the User-Agent , Accept , Accept-Charset , Accept-Encoding , and Accept-Language header fields and must not delete header fields. It must be possible for the server to reconstruct the original User Agent originated header fields by copying directly from the corresponding X-Device header field values (see 4.1.5.5 Original Header Fields ).

Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless: header fields unless one of the following applies:

  1. the user would be prohibited from accessing content as a result of the server responding that the request is "unacceptable" (see 4.3.3 4.2.5 Server Rejection of HTTP Request );

  2. the user has specifically requested a restructured desktop experience; experience (see 4.1.5.3 User Selection of Restructured Experience );

  3. the request is part of a sequence of requests to the same Web site and either it is technically infeasible not to adjust the request because of earlier interaction, or because doing so preserves consistency of user experience.

These circumstances are detailed in the following sections.

Note:

In this section, the concept of "Web site" is used (rather than "origin server") as some origin servers host many different Web sites. Since the concept of "Web site" is not strictly defined, proxies should use heuristics including comparisons of domain name to assess whether resources form part of the same "Web site".

Note:

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 4.2.9 Proxy Decision to Transform are not material.

4.1.5.2 Avoiding "Request Unacceptable" Responses

A proxy may 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 4.3.3 4.2.5 Server Rejection of HTTP Request ). A proxy may 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 may alter header field values without sending unaltered values in advance, providing that it subsequently assesses the response as described under 4.3.4 4.2.6 Receipt of Vary HTTP Header Field below, and is prepared to reissue the request with unaltered headers, header fields, and alter its subsequent behavior in respect of the Web site so that unaltered headers header fields are sent.

A proxy must not re-issue reissue a POST/PUT POST request with altered headers header fields when the response to the unaltered POST/PUT POST request has HTTP status code 200 (in other words, it may only send the altered request for a POST/PUT request when the unaltered one resulted in an HTTP 406 response, and not a "request unacceptable" response).

4.1.5.4 Sequence of Requests

When requesting resources that form part of the representation of a resource are included resources (e.g. style sheets, images), proxies should make the request for such resources with the same headers User-Agent header field as the request for the resource from which they are referenced.

For the purpose of consistency of representation, proxies may request linked resources (e.g. those referenced using the a element) that form part of the same Web site as a previously requested resource with the same headers header fields as the resource from which they are referenced.

When requesting linked resources that do not form part of the same Web site as the resource from which they are linked, proxies should not base their choice of headers header fields on a consistency of presentation premise.

4.1.5.5 Original Headers Header Fields

When forwarding an HTTP request with altered HTTP headers header fields, in addition to complying with the rules of normal HTTP operation, proxies must include in the request copies of the unaltered header field values in the form "X-Device-"<original header name> . For example, if the User-Agent header field has been altered, an X-Device-User-Agent header field must be added with the value of the received User-Agent header. header field.

Specifically the following mapping must be used:

Original Replacement Ref
User-Agent X-Device-User-Agent RFC2616 Section 14.43
Accept X-Device-Accept RFC2616 Section 14.1
Accept-Charset X-Device-Accept-Charset RFC2616 Section 14.2
Accept-Encoding X-Device-Accept-Encoding RFC2616 Section 14.3
Accept-Language X-Device-Accept-Language RFC2616 Section 14.4

Note:

The X-Device- prefix was chosen primarily on the basis that this is a 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 headers. fields. The treatment of received X-Device headers, header fields, which may happen where there are multiple transforming proxies, is undefined (see D J Scope for Future Work ).

4.2 Server Proxy Forwarding of Response to Proxy User Agent

4.2.1 Use of HTTP 406 Status

Servers In the following, proxies should must respond with an HTTP 406 Status (and not an HTTP 200 Status) if a request cannot be satisfied with content that meets check for the criteria specified by values presence of equivalent <meta http-equiv> elements in HTML content, if the relevant HTTP request headers. header field is not present.

4.2.3 Varying Representations 4.2.2 User Preferences

Servers should take account of user agent capabilities and formulate an appropriate experience according to those capabilities. Servers Proxies should must provide a means for users to select among available representations, should default to express preferences for inhibiting content transformation even when this has been chosen by the last selected representation and should provide a means of changing user as the selection. 4.2.3.1 Use of Vary HTTP Header If a server varies its representation according to examination of received HTTP headers then it default behavior. Those preferences must include a Vary HTTP header indicating this to be the case. If, in addition to, or instead of HTTP headers, a server varies its representation based maintained on other factors (e.g. source IP Address) then it must , in accordance with a user by user and Web site by Web site basis. [RFC 2616 HTTP] , include a Vary header containing the value '*'.

Servers Proxies may must base their actions on knowledge of behavior solicit re-expression of specific transforming proxies, as identified preferences in a Via header, but should not choose an Internet content type for a response based on an assumption or heuristics about behavior respect of any intermediaries. (e.g. a server should not choose Content-Type: application/vnd.wap.xhtml+xml solely on if the basis that it suspects that proxies will not transform content of this type). 4.2.3.2 Indication of Intended Presentation Media Type of Representation If a server has distinct representations that vary according starts to the target presentation media type, indicate that it should inhibit transformation of the response by including a Cache-Control: no-transform directive (see offers varying responses as discussed under 4.2.2 Server Origination of Cache-Control: no-transform ). In HTML content it should indicate the medium for which the representation is intended by including a link element identifying in its media attribute the target presentation media types of this representation and setting the href attribute to a valid local reference (i.e. use the fragment identifier (see [RFC 3986] section 3.5 ) added to the URI of the document being served to point to a valid target within the document). In addition it should include link elements identifying the target presentation media types of other available representations by setting the media attribute to indicate those representations and the href attribute to a URI without a fragment identifier. Note: The presence of link elements which do not contain a valid local reference does not indicate one way or another whether this representation is formatted for the presentation media types listed. Note: Some examples of the use 4.2.6 Receipt of the link element are included below in B Example Transformation Interactions Vary HTTP Header Field .

4.3 Proxy Forwarding of Response to User Agent

4.3.1 4.2.3 Receipt of Cache-Control: no-transform

If the response includes a Cache-Control: no-transform directive then proxies must not alter it other than to comply with transparent HTTP behavior as described in [RFC 2616 HTTP] Section 13.5.2 and Section 14.9.5 and other than as follows.

If a proxy determines that a resource as currently represented is likely to cause serious mis-operation misoperation of the user agent then it may advise the user that this is the case and must provide the option for the user to continue with unaltered content. content (and may provide other options too).

4.3.4 4.2.6 Receipt of Vary HTTP Header Field

If, in response to an HTTP request with altered headers that was A proxy may not preceded by an HTTP be carrying out content tasting as described under 4.1.5.2 Avoiding "Request Unacceptable" Responses if it anticipates receiving a "request unacceptable" response. However, if it makes a request with unaltered headers, a proxy altered header fields in these circumstances, and receives a response containing a Vary header field referring to one of the altered headers header fields then it should request the resource again with unaltered headers, it header fields. It should also update whatever heuristics it uses so that unaltered headers header fields are presented first in subsequent requests for this resource and it should resume the behavior described under 4.1.5.2 Avoiding "Request Unacceptable" Responses to avoid rejection of subsequent requests. resource.

4.2.8 WML Content

4.2.3.2 Indication of Intended Presentation Media Type

If the content is WML proxies should act in a transparent manner.

Note:

This does not affect the operation of Representation proxies that are also WAP Gateways.

.

4.3.6 4.2.9 Proxy Decision to Transform

In the absence of a Vary or no-transform directive (or a meta HTTP-Equiv element containing Cache-Control: no-transform ) proxies should not apply heuristics to transform content matching any of the response to determine whether it following rules unless the user has specifically requested transformation:

Examples of heuristics: Other factors that a proxy may take into account:

  • The Web site (see note ) has previously shown that it is contextually aware, even if the present response does not indicate this;

  • a claim of mobileOK Basic [mobileOK Basic Tests] conformance is indicated; the Content-Type or other aspects of the response (such as the DOCTYPE) are known to be specific to the device or class of device; Examples of mobile specific DOCTYPEs: -//OMA//DTD XHTML Mobile 1.2//EN -//WAPFORUM//DTD XHTML Mobile 1.1//EN -//WAPFORUM//DTD XHTML Mobile 1.0//EN -//W3C//DTD XHTML Basic 1.1//EN -//W3C//DTD XHTML Basic 1.0//EN) the user agent has features (such as linearization or zoom capabilities or other features which zoom) that allow it to present the content unaltered;

  • the URI of the response (following redirection or as indicated by the Content-Location HTTP header) indicates that the resource is intended for mobile use (e.g. the domain is *.mobi, wap.*, m.*, mobile.* or the leading portion of the path is /m/ or /mobile/); the response contains client-side client side scripts that may mis-operate misoperate if the resource is restructured;

  • the response is an HTML response and it includes <link> elements specifying alternatives according to presentation media type.

4.3.6.1 4.2.9.1 Alteration of Response

If a proxy alters the response then:

  1. It must add a Warning 214 Transformation Applied HTTP header; header field;

  2. The altered content should validate according to an appropriate published formal grammar; grammar and if XML must be well-formed ;

  3. It should indicate to the user that the content has been transformed for mobile presentation and provide an option to view the original, unmodified content.

4.2.9.2 Link Rewriting

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 that doing, proxies make unrelated resources appear as though they can transform the content of linked resources, if have the following provision same-origin and hence there is met. If a proxy does rewrite such links, it must advise the user danger of the introducing security implications vulnerabilities.

Note:

This section (on link rewriting) refers also to insertion of doing so links, frame flattening and must any other techniques that introduces the "same-origin" issue.

Note:

Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile adapted web search and navigation to the option web pages returned in the search results, or to avoid decryption and transformation 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 resources browser, but may not be required since all browser requests flow through the links refer to. CT Proxy.

If a proxy re-writes HTTPS links, replacement Proxies must not rewrite links when content transformation is prohibited.

Proxies must have the scheme https . preserve security between requests for domains that are not same-origin in respect of cookies and scripts.

5 Testing (Normative)

Operators of transforming content transformation proxies should make available interfaces that facilitate testing an interface through which the functions of Web sites accessed the proxy can be exercised. The operations possible through them and this interface should must make cover those necessary to settle the outcome of all conformance statements listed in section B.

The interface must be reachable from terminals with browsing capabilities connected to the Web via a conventional Internet access environment at the tester's premises; accessing the interface may necessitate adjusting standard Web browsing configuration parameters -- such interfaces as specifying a proxy IP address and port on a desktop browser, or activating a WAP setting on a mobile browser.

Such access must be granted under fair, reasonable and non-discriminatory conditions. In particular:

A References

CT Landscape
Content Transformation Landscape 1.0, Jo Rabin, Andrew Swainston (eds), W3C Working Draft 25 October 2007 (See http://www.w3.org/TR/ct-landscape/ http://www.w3.org/TR/2007/WD-ct-landscape-20071025/ )
RFC 2119
Key words for use in RFCs to Indicate Requirement Levels, , Request for Comments: 2119, S. Bradner, March 1997 (See http://www.ietf.org/rfc/rfc2119.txt )
RFC 2616 HTTP
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 http://tools.ietf.org/html/rfc2616 )
RFC 3986
Uniform Resource Identifier (URI): Generic Syntax, Request for Comments: 3986, T. Berners-Lee, R. Fielding, L. Masinter, January 2005 (See http://tools.ietf.org/html/rfc3986 )
RFC 3238 OPES
IAB Architectural and Policy Considerations for Open Pluggable Edge Services, Request for Comments: 3238, S. Floyd, L. Daigle, January 2002 (See http://tools.ietf.org/html/rfc3238 )
Device Independence Glossary
W3C Glossary of Terms for Device Independence, Rhys Lewis (ed), W3C Working Draft 18 January 2005
Best Practices
Mobile Web Best Practices 1.0 Basic Guidelines, Jo Rabin, Charles McCathieNevile (eds), W3C Proposed Recommendation, 2 November 2006 1l: To update 29 July 2008 (See http://www.w3.org/TR/mobile-bp/ http://www.w3.org/TR/2008/REC-mobile-bp-20080729/ )
mobileOK Basic Tests
W3C mobileOK Basic Tests, Tests 1.0, Sean Owen, Jo Rabin (eds), W3C Working Draft, 10 June Recommendation, 08 December 2008 1l: To update (See http://www.w3.org/TR/mobileOK-basic10-tests/ http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/ )
mobileOK Scheme
W3C mobileOK Scheme 1.0, Jo Rabin, Phil Archer (eds), W3C Note, 25 August 2009 (See http://www.w3.org/TR/2009/NOTE-mobileOK-20090825/ )
XHR
The XMLHttpRequest Object, Anne van Kesteren (ed), W3C Working Draft, 15 April 2008 (See http://www.w3.org/TR/XMLHttpRequest/ )
XML
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 http://www.w3.org/TR/xml/ )

B Conformance Statement

Editorial Note: Update to final location

See http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/ics-090923

C Internet Content Types associated with Mobile Content

D DOCTYPEs Associated with Mobile Content

E URI Patterns Associated with Mobile Web Sites

F Summary of User Preference Handling

User expression of preferences is referred to in several sections in this document. Those sections are:

  1. 1.4.2 Priority of Intention

  2. 4.1.4 Serving Cached Responses

  3. 4.1.5.3 User Selection of Restructured Experience

  4. 4.2.2 User Preferences

  5. 4.2.3 Receipt of Cache-Control: no-transform

  6. 4.2.9 Proxy Decision to Transform

  7. 4.2.9.1 Alteration of Response

  8. 4.2.9.3 HTTPS Link Rewriting

User preferences are also referred to non-normatively under H.1.4 Varying Representations .

G Example Transformation Interactions (Non-Normative)

B.3 G.3 Optimization based on Previous Server Interaction, Server has Changed its Operation

Proxy receives a request for resource P, that it has previously encountered as in B.2 G.2 Optimization based on Previous Server Interaction

Proxy forwards request with altered headers header fields

Response is 200 OK containing a Vary: User-Agent header field

Proxy notices that behavior has changed and re-issues reissues the request with original headers header fields

Response is 200 OK and proxy forwards it

H Informative Guidance for Origin Servers (Non-Normative)

Content providers may wish to follow these procedures in order to improve interoperability.

H.1 Server Response to Proxy

H.1.4 Varying Representations

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.

H.1.4.1 Use of Vary HTTP Header Field

If a server varies its representation according to examination of received HTTP header fields then [RFC 2616 HTTP] describes how to use the Vary header field to indicate this.

Servers that are aware of the presence of a transforming proxy, as identified by a Via HTTP Header field might alter their responses according to their knowledge of specific proxy behavior. When doing so it is good practice to make sure that the Internet content type for a response is correct for the actual content (e.g. a server should not choose Content-Type: application/vnd.wap.xhtml+xml because it suspects that proxies will not transform content of this type, if its content is not valid XHTML-MP).

H.1.4.2 Indication of Intended Presentation Media Type of Representation

If a server has distinct representations that vary according to the target presentation media type, it can inhibit transformation of the response by including a Cache-Control: no-transform directive (see H.1.3 Server Origination of Cache-Control: no-transform ).

In addition, in HTML content it can indicate the medium for which the representation is intended by including a link element identifying in its media attribute the target presentation media types of this representation and setting the href attribute to "Same-Document Reference" (see [RFC 3986] section 4.4 ) and in particular an empty href attribute is a "Same Document Reference".

In addition it is good practice to include link elements identifying the target presentation media types of other available representations in a similar manner.

If content for more than one presentation media type is served from the same URI, it is better not to use a link element identifying the presentation media types as the URI will appear to be a "same document reference", indicating to a client that this representation is suitable for all the named presentation media types. Instead, use a Vary HTTP header field indicating that the response varies according to the received User-Agent HTTP header field.

Note:

Some examples of the use of the link element are included above in G Example Transformation Interactions .

C I Applicability to Transforming Solutions which are Out of Scope (Non-Normative)

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 with using proprietary protocols and techniques, it is the combination of the client and the in-network network component that is regarded as the HTTP User Agent. The communication between the client and the in-network network component is therefore out of scope of this document.

Additionally, where some kind of administrative arrangement exists between a transforming proxy and an origin server for the purposes of transforming content on the origin server's behalf, this is also out of scope of this document.

In both of the above cases, it is recommended that when forwarding requests good practice to origin servers that proxies adhere to the provisions of this document in respect of providing information about the device and the original IP address.

D J Scope for Future Work (Non-Normative)

D.1 J.1 POWDER

The BPWG believes that POWDER will represent a powerful mechanism by which a server may express transformation preferences. Future work in this area may recommend the use of POWDER to provide a mechanism for origin servers to indicate more precisely which alternatives they have and what transformation they are willing to allow on them, and in addition to provide for Content Transformation proxies to indicate which services they are able to perform.

D.5 J.5 Amendment to and Refinement of HTTP

The BPWG believes that amendments to HTTP are needed to improve the inter operability interoperability of transforming proxies. For example, HTTP does not provide a way to distinguish between prohibition of any kind of transformation and the prohibition only of restructuring (and not recoding or compression).

At present HTTP does not provide a mechanism for communicating original header values (hence the use of X-Device- headers as discussed field values. The scheme based on X-Device prefixed fields described under 4.1.5 Alteration of HTTP Header Field Values ). records and clarifies an approach used to achieve this effect by some content transformation proxies. This scheme relies upon non-standard HTTP fields, which are identified by their prefix as experimental according to IETF standards (notably RFC 822 and RFC 2076), and are not included in the IANA registry of HTTP header fields. While the mechanism defined in that section, based on current practice, applies to conforming transformation proxy deployments, it is possible that in future, in collaboration with the IETF, this approach will be reconsidered. This implies that the specified X-Device prefixed fields may, at some time, become deprecated in favor of new equivalent fields, or that an entirely different approach will be taken to representing such values.

A number of mechanisms exist in HTTP which might be exploited given more precise definition of their operation - for example the OPTIONS method and the HTTP 300 (Multiple Choices) Status.

E Administrative Arrangements (Non-Normative) It is noted that there are means which fall outside of the scope of this document for establishing user preferences with content transformation proxies. It is anticipated that proxies will maintain preferences on a user by user and Web site by Web site basis, and will change their behavior in the light of changing circumstances as discussed under 4.3.4 Receipt of Vary HTTP Header . F K Acknowledgments (Non-Normative)

The editor acknowledges contributions of various kinds from members of the Mobile Web Best Practices Working Group and earlier from the Content Transformation Task Force . of that group.

The editor acknowledges significant written contributions from: