Guidelines for Web Content Transformation Guidelines 1l (Rev 12) Proxies 1w

1.4.1 IAB Considerations

that is unable or unwilling The BPWG made reference to deal with 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 request in IAB expressed its present form. concerns about privacy, control, monitoring, and accountability of such services.

1.4.2 Priority of Intention

The Content Transformation proxy needs to be able to tell the user agent: that it has applied transformations Web allows users considerable flexibility in respect of various kinds to the representation of content. The At the same time, Content Transformation proxy needs Providers may have a preferred manner in which they wish their content to be able to interact with represented. Content Transformation must reconcile these contrasting factors. In creating this Recommendation the user: to BPWG has determined that Content Transformation proxies should respect Content Providers intentions, where they are expressed, but may allow the user users to disable its features; choose other representations, except where Content Providers specifically prohibit this.

to alert the user to the fact The BPWG recognizes that it has transformed content and to allow access to an untransformed representation there is neither a systematic vocabulary for Content Provider Intentions, nor a systematic means of the content. Note: A more extensive discussion expression of the requirements such intentions. There is scope for these guidelines can be found further work in "Content Transformation Landscape" [CT Landscape] . this area (see J Scope for Future Work ).

3.1.1 4.1.1 Applicable HTTP Methods

Proxies should not intervene in methods other than GET, POST, HEAD and PUT. 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 if it requires the response body (in order to determine the characteristics of the a transformed response that it would return were if the user agent subsequently to issue issued a GET request for that content. 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. required (see also 4.1.4 Serving Cached Responses ).

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

3.1.2 4.1.2 no-transform directive in Request

If the request contains a Cache-Control: no-transform directive directive, proxies must not forward alter the request unaltered to the server, 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 noted below (see described in 3.1.6 4.1.6 Additional HTTP Headers Header Fields ). below.

3.1.3 4.1.3 Treatment of Requesters that are not Web browsers

Proxies must act as though a no-transform directive is present (see 3.1.2 no-transform directive in Request unless they are able positively Before altering aspects of an HTTP request proxies need to determine that take account of the user agent fact that HTTP is a Web browser. The mechanism by which a proxy recognizes the user agent used as a Web browser should use evidence from the transport mechanism for many applications other than "Traditional Browsing". Alteration of HTTP request, in particular the User-Agent and Accept headers. requests for those applications can cause serious misoperation.

3.1.4 4.1.4 Serving Cached Responses

Proxies should follow standard HTTP Aside from the usual caching procedures defined in respect of caching and should use cached copies of resources where this is [RFC 2616 HTTP] , in accordance with those procedures 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. Editorial Note1l: This hasn't been discussed before, what should we say about serving subsequent parts In this case proxies may for the sake of a response consistency of representation serve stale data but when doing so should notify the user that this is set to "no-cache" or whose expiry time has elapsed? the case and must provide a simple means of retrieving a fresh copy.

3.1.5 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 and must not delete header fields. It must be possible for the server to reconstruct the original User Agent originated header fields by copying directly from the corresponding X-Device header field values (see 4.1.5.5 Original 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 3.3.3 4.2.5 Server Rejection of HTTP Request ; );

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

3.1.6 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 3.1.6.1 4.1.6.1 Proxy Treatment of Via Header Field ).

3.2.2 Server Origination of Cache-Control: no-transform 4.2.1 Applicable Responses

Servers must include a Cache-Control: no-transform directive if one is received in the HTTP request. Servers Proxies should not include a Cache-Control: no-transform directive if, for any reason, they wish to inhibit transformation of the response. Note: Including a Cache-Control: no-transform directive can disrupt the behavior of WAP/WML proxies, because it can inhibit such proxies from converting WML to WMLC. Note: If a server is unable to add a Cache-Control HTTP header, intervene in HTML documents it should add a meta HTTP-Equiv element containing Cache-Control: no-transform . Editorial Note1l: I think this is here to be symmetrical with the section below on proxies taking account of it, however, this really applies to legacy servers that can do nothing else, so does it belong here? How much could a legacy server actually comply with this spec? Perhaps, response if anywhere, this needs to be moved to an appendix on "legacy servers" to accompany the other "things that out of scope components should do anyway?" request method was not HEAD, GET or POST.

3.2.3 Varying Representations 4.2.2 User Preferences

Servers should take account of user agent capabilities and formulate an appropriate experience according to those capabilities. Servers Proxies should must provide a means for users to select among available representations, should default to the last selected representation and should provide a means of changing the selection. Editorial Note1l: Above wording changed and elaborated from 1k, to be consistent with discussion at F2F and to proposed Best Practice in BP2. We did not resolve a mechanism express preferences for inhibiting content transformation even when content transformation has been chosen by which servers should indicate that they are offering the user choice in this way. 3.2.3.1 Use of Vary HTTP Header If a server varies its representation according to examination of received HTTP headers then it as the default behavior. Those preferences must include a Vary HTTP header indicating this to be the case. If, in addition to, or instead of HTTP headers, a server varies its representation based maintained on other factors (e.g. source IP Address) then it must , in accordance with [RFC 2616 HTTP] , include a Vary header containing the value '*'. user by user and Web site by Web site basis.

Servers Proxies may must base their actions on knowledge of behavior solicit re-expression of specific transforming proxies, as identified preferences in a Via header, but should not choose an Internet content type for a response based on an assumption or heuristics about behavior respect of any intermediaries. (e.g. a server should not choose Content-Type: application/vnd.wap.xhtml+xml solely on if the basis that it suspects that proxies will not transform content of this type). 3.2.3.2 Indication of Intended Presentation Media Type of Representation If a server has distinct representations that vary according starts to the target presentation media type, it should inhibit transformation of the response by including a Cache-Control: no-transform directive (see 3.2.2 Server Origination of Cache-Control: no-transform ). In HTML content it should indicate the medium for which the representation is intended by including link elements that it offers varying responses as follows: Include a link element identifying the target presentation media types of this representation by setting the media attribute and set the href attribute to a valid local reference (i.e. use the fragment identifier added to the URI of the document being served to point to a valid target within the document); Include link elements identifying the target presentation media types of other available representations by setting the media attribute to indicate those representations and set the href attribute to a URI without a fragment identifier. Note: The presence of the second usage of the link element discussed above in the absence of a link element conforming to the first usage does not indicate that this representation is or is not formatted for the presentation media types listed. Note: under Some examples of the use 4.2.6 Receipt of the link element are included below in B Example Transformation Interactions Vary HTTP Header Field .

3.3.1 4.2.3 Receipt of Cache-Control: no-transform

If the response includes a Cache-Control: no-transform directive then the response proxies must not remain unaltered 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 the 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).

3.3.2 Receipt 4.2.4 Use of Warning: 214 Transformation Applied Cache-Control: no-transform

If the response includes a Warning: 214 Transformation Applied HTTP header, proxies Proxies must not may apply use Cache-Control: no-transform to inhibit transformation by further transformation. proxies.

3.3.3 4.2.5 Server Rejection of HTTP Request

For compatibility with servers that do not implement this Recommendation (see 3.2.1 Use of HTTP 406 Status ), a proxy 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 one a response with an HTTP 406 Status.

3.3.4 4.2.6 Receipt of Vary HTTP Header Field

If, in response to an HTTP request with altered headers, that was A proxy may not preceded by an HTTP 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 unaltered headers, a proxy altered 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 and with unaltered header fields. It should also update whatever heuristics it uses so that unaltered headers header fields are always presented first in subsequent requests for this resource.

3.3.5 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 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 transparent manner.

3.3.6 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 (@@sic) 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™ ??? reference to the current representation conformance is indicated; ;

• the Content-Type DOCTYPE or other aspects of the response are known to be specific to the device or class of device (e.g. for HTML documents the DOCTYPE is "-//OMA//DTD XHTML Mobile 1.2//EN", "-//WAPFORUM//DTD XHTML Mobile 1.1//EN" "-//WAPFORUM//DTD content (if it has one) indicates XHTML-MP, XHTML Basic, WML or iMode as listed in D DOCTYPEs Associated with Mobile 1.0//EN" "-//W3C//DTD XHTML Basic 1.1//EN" and "-//W3C//DTD XHTML Basic 1.0//EN"); 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) 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 (e.g. the domain "handheld" in a resource that was itself handled transparently;

• a claim of mobileOK Basic [mobileOK Basic Tests] conformance is *.mobi, wap.*, m.*, mobile.* or 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 leading portion of present response does not indicate this;

• the path is /m/ user agent has features (such as linearization or /mobile/); 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.