W3C

Guidelines for Web Content Transformation Proxies - Implementation Conformance Statement

This version:
http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/ics
This document is an appendix to:
http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/
Latest version of "Guidelines for Web Content Transformation Proxies":
http://www.w3.org/TR/ct-guidelines/
Editor:
François Daoust, W3C
Contributors:
See Acknowledgments in Guidelines for Web Content Transformation Proxies.

Copyright ©2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document is an appendix to Guidelines for Web Content Transformation Proxies [CT-SPEC]. It provides a tabular checklist of all the normative clauses in the guidelines, sorted by topic. Please refer to Guidelines for Web Content Transformation Proxies [CT-SPEC] for the full statements and context description of the excerpts listed below.

Status of This Document

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 is derived from and is an appendix to Guidelines for Web Content Transformation Proxies [CT-SPEC], which is a draft document, produced by the Content Transformation Task Force of the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Please see the "Status of this document" section of the corresponding guidelines specification [CT-SPEC] for complete details about the status of the guidelines version from which this is extracted and which it accompanies.

Please send comments on this document to the Working Group's public email list [email protected], a publicly archived mailing list.

Introduction

This checklist includes excerpts of all the normative clauses of the Guidelines for Web Content Transformation Proxies [CT-SPEC] presented in a tabular format. The statements are presented by order of their topic.

The Conformance section of the Guidelines for Web Content Transformation Proxies specification requires Transformation Deployments that wish to claim conformance to the specification to make available a conformance statement that specifies the reasons for non-compliance with any clauses containing the key words should or should not. This presentation is intended to provide a base template for such a conformance statement.

The table includes spaces for scoring each statement: "Compliance" to assert compliance and "Reason for non-compliance" to specify the reasons for non-compliance with a given clause. Non-compliance to absolute requirements of the specification, i.e. normative statements that use the terms must, must not, shall or shall not, is forbidden. The "Reason for non-compliance" column of absolute requirements is marked as "N/A" (Not Applicable).

Clauses table

ID Guideline Compliance Reason for non-compliance
4.1.1 Applicable HTTP Methods
ta-41495 If the HTTP method is altered from HEAD to GET, proxies should (providing such action is in accordance with normal HTTP caching rules) cache the response so that a second GET request for the same content is not required (see also 4.1.4 Serving Cached Responses ).
ta-59418 Other than to convert between HEAD and GET proxies must not alter request methods. N/A
4.1.2 no-transform directive in Request
ta-52619 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. N/A
4.1.4 Serving Cached Responses
ta-60546 [...] 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 [...]
ta-19789 [...] and must provide a simple means of retrieving a fresh copy. N/A
4.1.5 Alteration of HTTP Header Field Values
ta-13090 Other than the modifications required by [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 [...]
ta-13875 [...] and must not delete header fields (see 4.1.5.5 Original Header Fields ). N/A
ta-5564 Other than to comply with transparent HTTP operation, proxies should not modify any request header fields unless one of the following applies: [...]
ta-32212 It is emphasized that requests must not be altered in the presence of Cache-Control: no-transform as described under 4.1.2 no-transform directive in Request . N/A
ta-34769 [...] 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".
4.1.5.1 Content Tasting
ta-37267 While complying with this section (4.1.5 Alteration of HTTP Header Field Values) and section 4.2.5 Receipt of Vary HTTP Header Field proxies should avoid making repeated requests for the same resource.
4.1.5.2 Avoiding "Request Unacceptable" Responses
ta-8535 A proxy must not reissue a POST request as it is unsafe (see [RFC 2616 HTTP] Section 9.1.1 ). N/A
4.1.5.3 User Selection of Restructured Experience
ta-38106 Proxies must assume that by default users will wish to receive a representation prepared by the Web site. N/A
ta-54089 [...] 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 I.1.4.2 Indication of Intended Presentation Media Type of Representation ), inform the user of that and allow them to select an alternative representation. N/A
ta-60333 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.5 Receipt of Vary HTTP Header Field ). N/A
4.1.5.4 Sequence of Requests
ta-16730 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.
ta-62477 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.1.5.5 Original Header Fields
ta-2614 When forwarding an HTTP request with altered HTTP header fields, in addition to complying with the rules of normal HTTP operation, proxies must include in the request additional fields of the form "X-Device-"<original header name> whose values are verbatim copies of the corresponding unaltered header field values, so that it is possible to reconstruct the original header field values. N/A
ta-23178 Specifically the following mapping must be used: [...] N/A
4.1.6 Additional HTTP Header Fields
ta-45717 proxies should add the IP address of the initiator of the request to the end of a comma separated list in an X-Forwarded-For HTTP header field; [...]
ta-9487 proxies must (in accordance with RFC 2616) include a Via HTTP header field (see 4.1.6.1 Proxy Treatment of Via Header Field ). N/A
4.1.6.1 Proxy Treatment of Via Header Field
ta-49612 Proxies should indicate their ability to transform content by including a comment in the Via HTTP header field consisting of the URI "http://www.
ta-18004 When forwarding Via header fields, proxies should not alter them by removing comments from them.
4.2 Proxy Forwarding of Response to User Agent
ta-32045 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. N/A
4.2.1 User Preferences
ta-14363 Proxies must 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. N/A
ta-21589 [...] Those preferences must be maintained on a user by user and Web site by Web site basis. N/A
ta-1707 Proxies must solicit re-expression of preferences in respect of a server if the server starts to indicate that it offers varying responses as discussed under 4.2.5 Receipt of Vary HTTP Header Field . N/A
4.2.2 Receipt of Cache-Control: no-transform
ta-45854 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. N/A
4.2.5 Receipt of Vary HTTP Header Field
ta-47303 [...] 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.
ta-52209 [...] It should also update whatever heuristics it uses so that unaltered header fields are presented first in subsequent requests for this resource.
4.2.6 Link to "handheld" Representation
ta-61891 If the response is an HTML response and it contains a <link rel="alternate" media="handheld" /> element (and the user agent is determined as being "handheld"), a proxy should request and process the referenced resource, unless the resource referenced is the current representation .
4.2.7 WML Content
ta-43472 If the content is WML proxies should act in a transparent manner.
4.2.8 Proxy Decision to Transform
ta-13796 In the absence of a Vary or no-transform directive (or a meta HTTP-Equiv element containing Cache-Control: no-transform) proxies should not transform content matching any of the following rules unless the user has specifically requested transformation: [...]
4.2.8.1 Alteration of Response
ta-11998 It must add a Warning 214 Transformation Applied HTTP header field; [...] N/A
ta-55014 The altered content should validate according to an appropriate published formal grammar [...]
ta-10803 [...] and if XML must be well-formed ; [...] N/A
ta-39889 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.8.2 Link Rewriting
ta-5078 Proxies must not rewrite links when content transformation is prohibited. N/A
ta-18105 Proxies must preserve security between requests for domains that are not same-origin in respect of cookies and scripts. N/A
4.2.8.3 HTTPS Link Rewriting
ta-43818 The practice of intercepting HTTPS links is strongly NOT RECOMMENDED .
ta-14570 If a proxy rewrites HTTPS links, it must advise the user of the security implications of doing so [...] N/A
ta-17637 [...] and must provide the option to bypass it and to communicate with the server directly. N/A
ta-53227 Notwithstanding anything else in this document, proxies must not rewrite HTTPS links in the presence of a Cache-Control: no-transform directive. N/A
ta-23497 If a proxy rewrites HTTPS links, replacement links must have the scheme https . N/A
ta-40493 When forwarding requests originating from HTTPS links proxies must include a Via header field as discussed under 4.1.6.1 Proxy Treatment of Via Header Field . N/A
ta-10117 When forwarding responses from servers proxies must notify the user of invalid server certificates. N/A
5 Testing (Normative)
ta-58462 Operators of content transformation proxies should make available an interface through which the functions of the proxy can be exercised.
ta-4172 [...] The operations possible through this interface must cover those necessary to settle the outcome of all conformance statements listed in section B. N/A
ta-23958 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; [...] N/A
ta-1181 Such access must be granted under fair, reasonable and non-discriminatory conditions. N/A

References

CT-SPEC
Guidelines for Web Content Transformation Proxies, Jo Rabin, mTLD Top Level Domain (dotMobi), Working Draft 11 February 2010, http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/.