This checklist includes excerpts of all defined normative clauses containing the key words should and should not from the
Guidelines for Web Content Transformation Proxies
[CT-SPEC] presented in a tabular format. The statements are presented by order of their topic.
The table includes spaces for scoring each statement, "yes" (compliance), "no" (non-compliance), "n/a" (not applicable), and comments. The comments section must specify the reasons for non-compliance with a given clause.
| Guidelines |
YES |
NO |
N/A |
|
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
|
| 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
should provide a simple means of retrieving a fresh
copy. |
|
|
|
|
4.1.5 Alteration of HTTP Header Values
|
Proxies should not change headers other than User Agent and Accept(-*) headers and must not delete headers. It must be possible for the server to reconstruct the original UA originated headers (see
4.1.5.5 Original Headers
). |
|
|
|
| Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless: |
|
|
|
| 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". |
|
|
|
|
4.1.5.1 Content Tasting
|
| The theoretical idempotency of GET requests is not always respected by
servers. In order, as far as possible, to avoid mis-operation 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. 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
). |
|
|
|
|
4.1.5.4 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 as the request
for the resource from which they are referenced. |
|
|
|
|
4.1.6 Additional HTTP Headers
|
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; |
|
|
|
|
4.1.6.1 Proxy Treatment of Via Header
|
Proxies must (in accordance with compliance to RFC
2616) include a Via HTTP header indicating their presence
and should indicate their ability to transform content by including a comment in the Via HTTP
header consisting of the URI "http://www.w3.org/ns/ct". |
|
|
|
|
4.2.1 Applicable Responses
|
| Proxies should not intervene in response if the request method was not HEAD, GET or POST. |
|
|
|
|
4.2.6 Receipt of Vary HTTP Header
|
A proxy may not 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 altered headers in these circumstances, and receives a response
containing a Vary header referring to one of the altered
headers then it should request the resource again with
unaltered headers. It should also update whatever heuristics
it uses so that unaltered headers 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, the CT-proxy
should request and process the referenced resource,
unless the resource referenced is the current resource as determined by the
presence of link elements as discussed under
D.1.3.2 Indication of Intended Presentation Media Type of Representation
.oops a reference to something that isn't normative any more
|
|
|
|
|
4.2.8 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 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.) |
|
|
|
|
4.2.8.1 Alteration of Response
|
| A proxy should strive for the best possible user
experience that the user agent supports. It should
only alter the format, layout, dimensions etc. to match the specific
capabilities of the user agent. For example, when resizing images, they
should only be reduced so that they are suitable for the specific user
agent, and this should not be done on a generic
basis. |
|
|
|
| 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. |
|
|
|
|
5 Testing (Normative)
|
| Operators of transforming proxies should make available interfaces
that facilitate testing of Web sites accessed through them and
should make such interfaces available through normal Internet
access paths. |
|
|
|