Guidelines for Web Content Transformation Proxies 1q

Editor's Draft 13 March 2009

This version:
Latest version:
Previous versions:
Draft 1p (diff)
Draft 1o (diff)
Draft 1n (diff)
Draft 1m (diff)
Draft 1l (diff)
Draft 1k (diff)
Jo Rabin, mTLD Top Level Domain (dotMobi)


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

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

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, 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
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 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
   Content Tasting
   Avoiding "Request Unacceptable" Responses
   User Selection of Restructured Experience
   Sequence of Requests
   Original Header Fields
        4.1.6 Additional HTTP Header Fields
   Proxy Treatment of Via Header Field
    4.2 Proxy Forwarding of Response to User Agent
        4.2.1 Applicable Responses
        4.2.2 User Preferences
        4.2.3 Receipt of Cache-Control: no-transform
        4.2.4 Use of Cache-Control: no-transform
        4.2.5 Server Rejection of HTTP Request
        4.2.6 Receipt of Vary HTTP Header Field
        4.2.7 Link to "handheld" Representation
        4.2.8 WML Content
        4.2.9 Proxy Decision to Transform
   Alteration of Response
   HTTPS Link Re-writing
5 Testing (Normative)


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

1 Introduction (Non-Normative)

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 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 [RFC 2616 HTTP] are to be used.

The BPWG made reference to Ineternet Architecture Board work on "Open Pluggable Edge Services" [RFC 3238 OPES] for various principles that underlie behavior of proxies. In this work the IAB expressed its concerns about privacy, control, monitoring, and accountability of such services.

The 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 inter-operability. 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 inter-action of some form).

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 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.

  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. 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. It includes also rewriting of URIs so that subsequent requests route via the proxy handling this 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.1 Classes of Product

The Content Transformation Guidelines specification has one class of products:

Transformation Deployment

A Transformation Deployment is the provision of non-transparent components in the path of HTTP requests and responses. Provisions that are applicable to a Transformation Deployment are identified in this document by use of the term "transforming proxy" or "proxy" in the singular or plural.

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.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.

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, proxies must not alter the request 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 described in 4.1.6 Additional HTTP Header Fields below.


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

4.1.4 Serving Cached Responses

Aside from the usual caching procedures defined 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 must provide a simple means of retrieving a fresh copy.

4.1.5 Alteration of HTTP Header Field Values

Proxies should not modify the values of header fields other than User Agent, Accept Accept-Charset and Accept-Encoding header fields and must not delete header fields. It must be possible for the server to reconstruct the original UA originated header fields by copying directly from the corresponding X-Device header field values (see Original Header Fields).

Editorial Note: Note that the need for copies of the original header values is (once again) in question.

Editorial Note: Note that the question of whether alteration of the User-Agent field solely in order to avoid a 406 response has *seemingly* not been answered definitively

Other than to comply with transparent HTTP operation, proxies should not modify any request header fields unless:

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

  2. the user has specifically requested a restructured desktop experience (see 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.


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".


The heuristics discussed in 4.2.9 Proxy Decision to Transform relating to URI patterns are not part of the decision to alter HTTP Header Field values. 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.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.2.6 Receipt of Vary HTTP Header Field 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.

A proxy must not re-issue a POST request with altered header fields when the response to the unaltered 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). User Selection of Restructured Experience

Proxies may offer users an option to choose to view a restructured experience even when a Web site offers a choice of user experience. If a user has made such a choice then proxies may alter header field values when requesting resources in order to reflect that choice, but must, on receipt of an indication from a Web site that it offers alternative representations (see D.1.3.2 Indication of Intended Presentation Media Type of Representation), inform the user of that and allow them to select an alternative representation.

Proxies should assume that by default users will wish to receive a representation prepared by the Web site. Proxies must assess whether a user's expressed preference for a restructured representation is still valid if a Web site changes its choice of representations (see 4.2.6 Receipt of Vary HTTP Header Field). Sequence of Requests

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

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

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

4.2 Proxy Forwarding of Response to User Agent

In the following, proxies must check for the presence of equivalent <meta http-equiv> elements in HTML content, if the relevant HTTP header field is not present.

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 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.

4.2.6 Receipt of Vary HTTP Header Field

A proxy may not be carrying out content tasting as described under Avoiding "Request Unacceptable" Responses 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 Vary header field referring to one of the altered header fields then it should request the resource again with unaltered header fields. It should also update whatever heuristics it uses so that unaltered header fields are presented first in subsequent requests for this resource.

4.2.8 WML Content

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


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

4.2.9 Proxy Decision to Transform

Editorial Note: Much of this needs to be re-organised ref resolutions on Mandatory heuristics, however pursuant to the resolution:

Editorial Note: The editor notes that the BPWG seeks further examples of heuristics.

In the absence of a Vary or no-transform directive (or a meta HTTP-Equiv element containing Cache-Control: no-transform) proxies should apply heuristics to the response to determine whether it is appropriate to restructure or recode it (in the presence of such directives, heuristics should not be used.)

Examples of heuristics:

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

  • a claim of mobileOK Basic [mobileOK Basic Tests] conformance is indicated;

  • the Content-Type or other aspects of the response (such as the DOCTYPE) are known to be specific to the device or class of device (see E Examples of Internet Content Types, DOCTYPEs and URI Patterns;

  • the user agent has features (such as linearization or 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 field) or the leading portion of the path indicates that the resource is intended for mobile use (see E Examples of Internet Content Types, DOCTYPEs and URI Patterns);

  • the response contains client-side scripts that may mis-operate if the resource is restructured;

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

If a proxy alters the response then:

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

  2. The altered content should validate according to an appropriate published formal 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. HTTPS Link Re-writing

Editorial Note: Note that the following is under active discussion. One view says that HTTPS link rewriting is unacceptable under any circumstances. Note also that the question of whether it is acceptable to rewrite any link has been opened (because of security considerations relating to [same domain] concerns)

Editorial Note: g) and others ...

If a proxy rewrites HTTPS links, it must advise the user of the security implications of doing so and must provide the option by-pass it and to communicate with the server directly.

Notwithstanding anything else in this document, proxies must not rewrite HTTPS links in the presence of a Cache-Control: no-transform directive.

If a proxy re-writes HTTPS links, replacement links must have the scheme https.

When forwarding requests originating from HTTPS links proxies must include a Via header field as discussed under Proxy Treatment of Via Header Field.

When forwarding responses from servers proxies must notify the user of invalid server certificates.

Add some stuff below under guidance for servers


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.

5 Testing (Normative)

Operators of content transformation proxies should make available an interface through which the functions of the proxy can be exercised. The operations possible through this interface must 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 as specifying a proxy IP address and port on a desktop browser, or activating a WAP setting on a mobile browser.

Editorial Note: Does this need to be publically accessible?

A References

CT Landscape
Content Transformation Landscape 1.0, Jo Rabin, Andrew Swainston (eds), W3C Working Draft 25 October 2007 (See
RFC 2119
Key words for use in RFCs to Indicate Requirement Levels, , Request for Comments: 2119, S. Bradner, March 1997 (See
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
RFC 3986
Uniform Resource Identifier (URI): Generic Syntax, Request for Comments: 3986, T. Berners-Lee, R. Fielding, L. Masinter, January 2005 (See
IAB Architectural and Policy Considerations for Open Pluggable Edge Services, Request for Comments: 3238, S. Floyd, L. Daigle, January 2002 (See
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 (See
mobileOK Basic Tests
W3C mobileOK Basic Tests, Sean Owen, Jo Rabin (eds), W3C Working Draft, 10 June 2008 1l: To update (See
The XMLHttpRequest Object, Anne van Kesteren (ed), W3C Working Draft, 15 April 2008 (See

B Conformance Statement

See example conformacne statement from Francois (link below) and his covering note


C Example Transformation Interactions (Non-Normative)

C.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 C.2 Optimization based on Previous Server Interaction

Proxy forwards request with altered header fields

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

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

Response is 200 OK and proxy forwards it

D Informative Guidance for Origin Servers (Non-Normative)

Content providers may wish to follow these procedures in order to improve inter-operability.

D.1 Server Response to Proxy

D.1.3 Varying Representations

It is good practice [ref]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.

D.1.3.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).

D.1.3.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 D.1.2 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 but do we have a reference for this 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.

I'm really not sure this is right actually. Think we need to bang on the TAG's door again.


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

E Examples of Internet Content Types, DOCTYPEs and URI Patterns (Non-Normative)

Internet Content Types that are sometimes or usually associated with content intended for delivery to mobile devices:

Editorial Note: h) and Mandatory Heuristics ...

DOCTYPEs sometimes or usually associated with content intended for mobile delivery

URI patterns sometimes associated with Mobile Web sites

F 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 component that is regarded as the HTTP User Agent. The communication between the client and the in-network component is therefore out of scope of this document.

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

In both of the above cases, it is good practice but do we have a reference for this to adhere to the provisions of this document in respect of providing information about the device and the original IP address.

G Scope for Future Work (Non-Normative)


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.

H Acknowledgments (Non-Normative)

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

The editor acknowledges significant written contributions from: