Copyright ©2008 W3C ® ( MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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 public-bpwg-ct@w3.org, a publicly archived mailing list.
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).
Guideline | Compliance | Reason for non-compliance | |
---|---|---|---|
4.1.1 Applicable HTTP Methods | |||
Proxies should not intervene in methods other than GET, POST, HEAD. | |||
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 ). | |||
4.1.4 Serving Cached Responses | |||
[...] 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 [...] | |||
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 [...] |
|||
Other than to comply with transparent HTTP operation, proxies should not modify any request header fields unless: [...] | |||
[...] 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 | |||
[...] In order, as far as possible, to avoid misoperation of such content, proxies should avoid issuing duplicate requests [...] | |||
[...] and specifically should not issue duplicate requests for comparison purposes. | |||
4.1.5.3 User Selection of Restructured Experience | |||
Proxies should assume that by default users will wish to receive a representation prepared by the Web site. | |||
4.1.5.4 Sequence of Requests | |||
[...] 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. |
|||
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.6 Additional HTTP Header Fields | |||
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; [...] |
|||
4.1.6.1 Proxy Treatment of Via Header Field | |||
[...] and should indicate their ability to transform content by including a comment in the Via HTTP header field consisting of the URI "http://www.w3.org/ns/ct". |
|||
When forwarding Via header fields, proxies should
not alter them by removing comments from them. |
|||
4.2.1 Applicable Responses | |||
Proxies should not intervene in the response if the request method was not HEAD, GET or POST. | |||
4.2.6 Receipt of Vary HTTP Header Field | |||
[...] 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.7 Link to "handheld" Representation | |||
If the response is an HTML response and it contains a <link
rel="alternate" media="handheld" /> element, a proxy
should request and process the referenced resource,
unless the resource referenced is the current resource as determined by the
presence of link elements. |
|||
4.2.8 WML Content | |||
If the content is WML proxies should act in a transparent manner. | |||
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 transform content matching the following rules unless the user has specifically requested transformation: [...] |
|||
4.2.9.1 Alteration of Response | |||
The altered content should validate according to an appropriate published formal grammar [...] | |||
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.3 HTTPS Link Rewriting | |||
The practice of intercepting HTTPS links is strongly NOT RECOMMENDED . | |||
5 Testing (Normative) | |||
Operators of content transformation proxies should make available an interface through which the functions of the proxy can be exercised. |