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 header fields as described in 4.1.6 Additional
HTTP Header Fields below.
Note:
An example of the use of Cache-Control:
no-transform is the issuing of asynchronous HTTP requests,
perhaps by means of XMLHttpRequest [XHR] ,
which may include such a directive in order to prevent
transformation of both the request and the response.
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 must provide a simple
means of retrieving a fresh copy.
4.1.5 Alteration of HTTP Header
Field Values
Aside from Other than the usual
procedures defined in 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 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 header fields unless one of the following applies:
-
the user would be prohibited from accessing content as a result
of the server responding that the request is "unacceptable" (see
4.2.5 4.2.4 Server Rejection of HTTP Request
);
-
the user has specifically requested a restructured desktop experience (see
4.1.5.3 User
Selection of Restructured Experience );
-
the request is part of a sequence of requests to comprising either
included resources or linked resources on 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 (see 4.1.5.4 Sequence of user
experience. Requests
).
These circumstances are detailed in the following sections.
Note:
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".
Note:
The URI referred to in the request plays no part in determining
whether or not to alter HTTP request header field values. In
particular the patterns mentioned in 4.2.9 4.2.8 Proxy Decision to Transform are
not material.
4.1.5.2 Avoiding "Request
Unacceptable" Responses
A proxy may reissue a request with altered HTTP
header field values if a previous request with unaltered values
resulted in the origin server rejecting the request as
"unacceptable" (see 4.2.5 4.2.4 Server
Rejection of HTTP Request ). A proxy
may apply heuristics of various kinds to assess,
in advance of sending unaltered header field values, whether the
request is likely to cause a "request unacceptable" response. If it
determines that this is likely then it may alter
header field values without sending unaltered values in advance,
providing that it subsequently assesses the response as described
under 4.2.6 4.2.5 Receipt of Vary HTTP Header Field
below, and is prepared to reissue the request with unaltered header
fields, and alter its subsequent behavior in respect of the Web
site so that unaltered header fields are sent.
A proxy must not reissue a POST
request with altered header fields when the
response to the unaltered POST request has HTTP status code 200 (in
other words, as it may only send the altered request for a POST request
when the unaltered one resulted in an HTTP 406 response, and not a
"request unacceptable" response). is
unsafe (see [RFC
2616 HTTP] Section 9.1.1 ).
4.1.5.3 User Selection of Restructured Experience
Proxies must assume that by
default users will wish to receive a representation prepared by the
Web site.
Proxies may offer users an option to choose to
view a restructured experience even when a Web site offers a choice
of user experience. 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 H.1.4.2 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.
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 4.2.5 Receipt of Vary HTTP Header Field
).
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 field as the request for
the resource from which they are referenced.
For the purpose of consistency of representation, proxies
may request linked resources (e.g. those
referenced using the a element) that form part of the
same Web site as a previously requested resource with the same
header fields as 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.5.5 Original Header Fields
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 in values, so that it
is possible to reconstruct the form
"X-Device-"<original original
header name> . field values. For example, if the
User-Agent header field has been altered, an
X-Device-User-Agent header field must would be added
with the value of the received User-Agent header
field.
Specifically the following mapping must be used:
Note:
The X-Device- prefix was chosen primarily on the
basis that this is an already existing convention. It is noted that
the values encoded in such header fields may not ultimately derive
from a device, they are merely received fields. The treatment of
received X-Device header fields, which may happen
where there are multiple transforming proxies, is undefined (see
J K Scope for Future Work ).