Guidelines for Web Content Transformation Proxies 1p 1w

1.4.1 IAB Considerations

The BPWG made reference to Internet Architecture Board (IAB) 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.

1.4.2 Priority of Intention

The Web allows users considerable flexibility in respect of the representation of content. At the same time, Content Providers may have a preferred manner in which they wish their content to be represented. Content Transformation must reconcile these contrasting factors. In creating this Recommendation the BPWG has determined that Content Transformation proxies should respect Content Providers intentions, where they are expressed, but may allow users to choose other representations, except where Content Providers specifically prohibit this.

The BPWG recognizes that there is neither a systematic vocabulary for Content Provider Intentions, nor a systematic means of expression of such intentions. There is scope for further work in this area (see J Scope for Future Work ).

4.1.1 Applicable HTTP Methods

Proxies should not intervene in methods other than GET, POST, HEAD.

User agents sometimes issue HTTP HEAD requests in order to determine if a resource is of a type and/or size that they are capable of handling. A transforming proxy may convert a HEAD request into a GET request (in order to determine the characteristics of a transformed response that it would return if the user agent subsequently issued a GET request for the same resource).

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

Other than to convert between HEAD and GET proxies must not alter request methods.

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 headers header fields as described in 4.1.6 Additional HTTP Headers Header Fields below.

4.1.3 Treatment of Requesters that are not Web browsers

Before altering aspects of an HTTP request proxies need to take account of the fact that HTTP is used as a transport mechanism for many applications other than "Traditional Browsing". Alteration of HTTP requests for those applications can cause serious mis-operation. misoperation.

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 must provide a simple means of retrieving a fresh copy.

4.1.5 Alteration of HTTP Header Field Values

Proxies Aside from the usual procedures defined in [RFC 2616 HTTP] proxies should not change headers modify the values of header fields other than the User Agent User-Agent ,Accept ,Accept-Charset ,Accept-Encoding , and Accept(-*) Accept-Language headers header fields and must not delete headers. header fields. It must be possible for the server to reconstruct the original UA User Agent originated headers header fields by copying directly from the corresponding X-Device header field values (see 4.1.5.5 Original Headers 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.2.5 Server Rejection of HTTP Request );

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

4.1.6 Additional HTTP Headers Header Fields

Irrespective of the presence of a no-transform directive:

• 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; header field;

• proxies must include a Via HTTP header field (see 4.1.6.1 Proxy Treatment of Via Header Field ).

4.2.1 Applicable Responses

Proxies should not intervene in the response if the request method was not HEAD, GET or POST.

4.2.2 User Preferences

Proxies must provide a means for users to express preferences for inhibiting content transformation. transformation even when content transformation has been chosen by the user as the default behavior. Those preferences must be maintained on a user by user and Web site by Web site basis.

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.6 Receipt of Vary HTTP Header Field .

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.2.4 Use of Cache-Control: no-transform

Proxies may use Cache-Control: no-transform to inhibit transformation by further proxies.

4.2.5 Server Rejection of HTTP Request

Proxies may treat responses with an HTTP 200 Status as though they were responses with an HTTP 406 Status if it has determined that the content (e.g. "Your browser is not supported") is equivalent to a response with an HTTP 406 Status.

4.2.6 Receipt of Vary HTTP Header Field

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

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 a proxy should request and process the referenced resource, unless the resource referenced is the current resource representation .

4.2.8 WML Content

If the content is WML proxies should act in a reference to something that isn't normative any more transparent manner.

4.2.8 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 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 transform content matching any of heuristics: the following rules unless the user has specifically requested transformation:

• The Web site (see note ) has previously shown that it is contextually aware, even if the present response does not indicate this; content is HTML and contains <link rel="alternate" media="handheld"/> with a claim of mobileOK Basic [mobileOK Basic Tests] reference to the current representation conformance is indicated; ;

• the Content-Type DOCTYPE or other aspects of the response (such as the DOCTYPE) are known to be specific to the device content (if it has one) indicates XHTML-MP, XHTML Basic, WML or class of device (see iMode as listed in E Examples of Internet Content Types, D DOCTYPEs and URI Patterns Associated with Mobile Content ;

• the user agent Content-Type has linearization or zoom capabilities or other features which allow it to present the content unaltered; a value listed in C Internet Content Types associated with Mobile Content .

• the URI of the response (following redirection or as indicated by the Content-Location HTTP header) or the leading portion of the path indicates that header field) matches a pattern listed in E URI Patterns Associated with Mobile Web Sites ;

• the response contains a resource that is intended referenced as an included resource suitable for mobile use (see "handheld" in a resource that was itself handled transparently;

  E Examples

• a claim of Internet Content Types, DOCTYPEs and URI Patterns mobileOK Basic [mobileOK Basic Tests] conformance is indicated (see [mobileOK Scheme] for how such a claim may be indicated).

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;

• the user agent has features (such as linearization or zoom) that allow it to present the content unaltered;

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