Copyright
© 2008
© 2009
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This document is an editors' copy that has no official standing.
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 reflects group resolutions on comments received on the previous Last Call Working Draft .
Publication as a Group Working Draft of a proposed normative Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the Content Transformation Task Force of the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . 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 document was produced under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy .
1
Introduction
(Non-Normative)
1.1
Purpose
1.2
Audience
1.3
Scope
2
Terminology
(Normative)
2.1
Types
of
Proxy
2.2
Types
of
Transformation
3
Conformance
(Normative)
3.1
Classes
of
Product
3.2
Normative
and
Informative
Parts
3.3
Normative
Language
for
Conformance
Requirements
3.4
Transformation
Deployment
Conformance
4
Behavior
of
Components
(Normative)
4.1
Proxy
Forwarding
of
Request
4.1.1
Applicable
HTTP
Methods
4.1.2
no-transform
directive
in
Request
4.1.3
Treatment
of
Requesters
that
are
not
Web
browsers
4.1.4
Serving
Cached
Responses
4.1.5
Alteration
of
HTTP
Header
Field
Values
4.1.5.1
Content
Tasting
4.1.5.2
Avoiding
"Request
Unacceptable"
Responses
4.1.5.3
User
Selection
of
Restructured
Experience
4.1.5.4
Sequence
of
Requests
4.1.5.5
Original
Headers
Header
Fields
4.1.6
Additional
HTTP
Headers
Header
Fields
4.1.6.1
Proxy
Treatment
of
Via
Header
Field
4.2
Proxy
Forwarding
of
Response
to
User
Agent
4.2.1
Applicable
Responses
4.2.2
User
Preferences
4.2.3
Receipt
of
Cache-Control:
no-transform
4.2.4
Use
of
Cache-Control:
no-transform
4.2.5
Server
Rejection
of
HTTP
Request
4.2.6
Receipt
of
Vary
HTTP
Header
Field
4.2.7
Link
to
"handheld"
Representation
4.2.8
WML
Content
4.2.9
Proxy
Decision
to
Transform
4.2.8.1
4.2.9.1
Alteration
of
Response
4.2.8.2
4.2.9.2
HTTPS
Link
Re-writing
5
Testing
(Normative)
A
References
B
Conformance
Statement
C
Example
Transformation
Interactions
(Non-Normative)
C.1
Basic
Content
Tasting
by
Proxy
C.2
Optimization
based
on
Previous
Server
Interaction
C.3
Optimization
based
on
Previous
Server
Interaction,
Server
has
Changed
its
Operation
C.4
Server
Response
Indicating
that
this
Representation
is
Intended
for
the
Target
Device
C.5
Server
Response
Indicating
that
another
Representation
is
Intended
for
the
Target
Device
D
Informative
Guidance
for
Origin
Servers
(Non-Normative)
D.1
Server
Response
to
Proxy
D.1.1
Use
of
HTTP
406
Status
D.1.2
Server
Origination
of
Cache-Control:
no-transform
D.1.3
Varying
Representations
D.1.3.1
Use
of
Vary
HTTP
Header
Field
D.1.3.2
Indication
of
Intended
Presentation
Media
Type
of
Representation
E
Examples
of
Internet
Content
Types,
DOCTYPEs
and
URI
Patterns
(Non-Normative)
F
Applicability
to
Transforming
Solutions
which
are
Out
of
Scope
(Non-Normative)
G
Scope
for
Future
Work
(Non-Normative)
G.1
POWDER
G.2
link
HTTP
Header
Field
G.3
Sources
of
Device
Information
G.4
Inter
Proxy
Communication
G.5
Amendment
to
and
Refinement
of
HTTP
H
Acknowledgments
(Non-Normative)
The overall objective of this document is to provide a means, as far as is practical, for users to be provided with at least a "functional user experience" [Device Independence Glossary] of the Web, when mobile, taking into account the fact that an increasing number of content providers create experiences specially tailored to the mobile context which they do not wish to be altered by third parties. Equally it takes into account the fact that there remain a very large number of Web sites that do not provide a functional user experience when perceived on many mobile devices.
The
BPWG
is
not
chartered
to
create
new
technology
-
its
role
is
to
advise
on
best
practice
for
use
of
existing
technology.
In
satisfying
Content
Transformation
requirements,
existing
HTTP
headers,
header
fields,
directives
and
behaviors
must
be
respected,
and
as
far
as
is
practical,
no
extensions
to
[RFC
2616
HTTP]
are
to
be
used.
The BPWG made reference to Ineternet Architecture Board 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.
The recommendations in this document refer to interactions of a proxy and do not refer to any presumed aspects of the internal operation of the proxy. For this reason, the document does not discuss use of "allow" and "disallow" lists (though it does discuss behavior that is induced by the implementation of such lists). In addition it does not discuss details of how transformation is carried out except if this is reflected in inter-operability. For this reason, it does not discuss the insertion or insertion of headers and footers or any other specific behaviors (though it does discuss the need for essential user inter-action of some form).
Alteration of HTTP requests and responses is not prohibited by HTTP other than in the circumstances referred to in [RFC 2616 HTTP] Section 13.5.2 and Section 14.9.5 .
HTTP defines two types of proxy: transparent proxies and non-transparent proxies. As discussed in [RFC 2616 HTTP] Section 1.3, Terminology :
"A transparent proxy is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A non-transparent proxy is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies."
This document elaborates the behavior of non-transparent proxies, when used for Content Transformation in the context discussed in [CT Landscape] .
There are three classes of operation on responses:
Restructuring
content
is
a
process
whereby
the
original
layout
is
altered
so
that
content
is
added
or
removed
or
where
the
spatial
or
navigational
relationship
of
parts
of
content
is
altered,
e.g.
by
linearization
(i.e.
reordering
presentation
elements,
especially
tables,
so
that
they
fit
on
a
narrow
display
and
can
be
traversed
without
horizontal
scrolling)
or
pagination.
pagination
(i.e.
splitting
a
document
too
large
to
be
stored
in
or
transmitted
to
the
terminal
in
one
piece,
so
that
it
can
be
nevertheless
accessed
by
browsing
through
a
succession
of
smaller
interlinked
documents).
It
also
includes
rewriting
URIs
so
that
subsequent
requests
are
routed
via
the
proxy
handling
the
response.
It
includes
also
rewriting
of
URIs
so
that
subsequent
requests
route
via
the
proxy
handling
this
response.
Recoding content
Optimizing content
The Content Transformation Guidelines specification has one class of products:
A Transformation Deployment is the provision of non-transparent components in the path of HTTP requests and responses. Provisions that are applicable to a Transformation Deployment are identified in this document by use of the term "transforming proxy" or "proxy" in the singular or plural.
The key words must , must not , required , shall , shall not , should , should not , recommended , may , and optional in this Recommendation have the meaning defined in [RFC 2119] .
A Transformation Deployment conforms to these guidelines if it follows the statements in 4.1 Proxy Forwarding of Request , 4.2 Proxy Forwarding of Response to User Agent and 5 Testing (Normative) .
A Transformation Deployment that wishes to claim conformance must make available a conformance statement B Conformance Statement that specifies the reasons for non-compliance with any clauses containing the key words should and should not .
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 ).
Other than to convert between HEAD and GET proxies must not alter request methods.
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.
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.
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.
Proxies
should
not
change
headers
modify
the
values
of
header
fields
other
than
User
Agent
,
Accept
Accept-Charset
and
Accept(-*)
Accept-Encoding
headers
header
fields
and
must
not
delete
headers.
header
fields.
It
must
be
possible
for
the
server
to
reconstruct
the
original
UA
originated
headers
header
fields
by
copying
directly
from
the
corresponding
X-Device
header
field
values
(see
4.1.5.5
Original
Headers
Header
Fields
).
Editorial Note: Note that the need for copies of the original header values is (once again) in question.
Editorial Note: Note that the question of whether alteration of the User-Agent field solely in order to avoid a 406 response has *seemingly* not been answered definitively
Other
than
to
comply
with
transparent
HTTP
operation,
proxies
should
not
modify
any
request
headers
header
fields
unless:
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 );
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 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.
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 heuristics discussed in 4.2.9 Proxy Decision to Transform relating to URI patterns are not part of the decision to alter HTTP Header Field values.
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
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
Receipt
of
Vary
HTTP
Header
Field
below,
and
is
prepared
to
reissue
the
request
with
unaltered
headers,
header
fields,
and
alter
its
subsequent
behavior
in
respect
of
the
Web
site
so
that
unaltered
headers
header
fields
are
sent.
A
proxy
must
not
re-issue
a
POST
request
with
altered
headers
header
fields
when
the
response
to
the
unaltered
POST
request
has
HTTP
status
code
200
(in
other
words,
it
may
only
send
the
altered
request
for
a
POST/PUT
request
when
the
unaltered
one
resulted
in
an
HTTP
406
response,
and
not
a
"request
unacceptable"
response).
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 D.1.3.2 Indication of Intended Presentation Media Type of Representation ), inform the user of that and allow them to select an alternative representation.
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 Field ).
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
headers
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
headers
header
fields
on
a
consistency
of
presentation
premise.
The
X-Device-
prefix
was
chosen
primarily
on
the
basis
that
this
is
a
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
headers.
fields.
The
treatment
of
received
X-Device
headers,
header
fields,
which
may
happen
where
there
are
multiple
transforming
proxies,
is
undefined
(see
G
Scope
for
Future
Work
).
Irrespective
of
the
presence
of
a
no-transform
directive:
Via
Header
Field
Editorial Note: I don't know why this is useful. What is a server expected to do as a result?
According
to
[RFC
2616
HTTP]
Section
14.45
Via
header
field
comments
"
may
be
removed
by
any
recipient
prior
to
forwarding
the
message".
However,
the
justification
for
removing
such
comments
is
based
on
memory
limitations
of
early
proxies,
most
modern
proxies
do
not
suffer
such
limitations.
Proxies should not intervene in the response if the request method was not HEAD, GET or POST.
Proxies must provide a means for users to express preferences for inhibiting content transformation. 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 .
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 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.
Cache-Control:
no-transform
Proxies
may
use
Cache-Control:
no-transform
to
inhibit
transformation
by
further
proxies.
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.
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
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
If the content is WML or WBMP? proxies should act in a transparent manner.
Note:
This does not affect the operation of proxies that are also WAP Gateways.
Editorial Note: Much of this needs to be re-organised ref resolutions on Mandatory heuristics , however pursuant to the resolution:
Editorial Note: The editor notes that the BPWG seeks further examples of heuristics.
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 of heuristics:
The Web site (see note ) has previously shown that it is contextually aware, even if the present response does not indicate this;
a claim of mobileOK Basic [mobileOK Basic Tests] conformance is indicated;
the
Content-Type
or
other
aspects
of
the
response
(such
as
the
DOCTYPE)
are
known
to
be
specific
to
the
device
or
class
of
device
(see
E
Examples
of
Internet
Content
Types,
DOCTYPEs
and
URI
Patterns
;
the
user
agent
has
features
(such
as
linearization
or
zoom
capabilities
or
other
features
which
zoom)
that
allow
it
to
present
the
content
unaltered;
the
URI
of
the
response
(following
redirection
or
as
indicated
by
the
Content-Location
HTTP
header)
header
field)
or
the
leading
portion
of
the
path
indicates
that
the
resource
is
intended
for
mobile
use
(see
E
Examples
of
Internet
Content
Types,
DOCTYPEs
and
URI
Patterns
);
the response contains client-side scripts that may mis-operate if the resource is restructured;
the
response
is
an
HTML
response
and
it
includes
<link>
elements
specifying
alternatives
according
to
presentation
media
type.
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
Other
than
as
noted
in
this
section
the
specific
capabilities
nature
of
the
user
agent.
For
example,
when
resizing
images,
they
should
only
be
reduced
so
restructuring
that
they
are
suitable
for
the
specific
user
agent,
is
carried
out,
any
character
encoding
alterations
and
this
should
not
be
done
on
a
generic
basis.
what
is
omitted
and
what
is
inserted
is,
as
discussed
in
1.3
Scope
,
out
of
scope
of
this
document.
If a proxy alters the response then:
It
must
add
a
Warning
214
Transformation
Applied
HTTP
header;
header
field;
The
altered
content
should
validate
according
to
an
appropriate
published
formal
grammar;
grammar
and
if
XML
must
be
well-formed
;
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.
If
a
proxy
re-writes
HTTPS
links,
replacement
links
must
have
the
scheme
https
.
When
forwarding
requests
originating
from
HTTPS
links
proxies
must
include
a
Via
header
field
as
discussed
under
4.1.6.1
Proxy
Treatment
of
Via
Header
Field
.
When forwarding responses from servers proxies must notify the user of invalid server certificates.
Add some stuff below under guidance for servers
Note:
For clarity it is emphasized that it is not possible for a transforming proxy to transform content accessed via an HTTPS link without breaking end-to-end security.
Some
lovely
text
See
example
conformacne
statement
from
Francois
goes
here.
(link
below)
and
his
covering
note
See http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/ics-081107
Request
resource
with
original
headers
header
fields
If the response is a 406 response:
If
the
response
contains
Cache-Control:
no-transform
,
forward
it
Otherwise
re-request
with
altered
headers
header
fields
If the response is a 200 response:
Otherwise assess whether the 200 response is a form of "Request Unacceptable"
Proxy receives a request for resource P that it has not encountered before
Response is a desktop oriented representation of the resource
Proxy transforms this response into content that the user agent can display well and forwards it
Proxy receives a further request for the resource P
Response is a desktop oriented representation of the resource
Proxy transforms this response into content that the user agent can display well and forwards it
Proxy receives a request for resource P, that it has previously encountered as in C.2 Optimization based on Previous Server Interaction
Proxy
forwards
request
with
altered
headers
header
fields
Response
is
200
OK
containing
a
Vary:
User-Agent
header
field
Proxy
notices
that
behavior
has
changed
and
re-issues
request
with
original
headers
header
fields
Response is 200 OK and proxy forwards it
Content providers may wish to follow these procedures in order to improve inter-operability.
Vary
HTTP
Header
Field
If
a
server
varies
its
representation
according
to
examination
of
received
HTTP
headers
header
fields
then
[RFC
2616
HTTP]
describes
how
to
use
the
Vary
header
field
to
indicate
this.
Servers
that
are
aware
of
the
behavior
presence
of
specific
a
transforming
proxies,
proxy,
as
identified
in
by
a
Via
header
make
choose
to
take
advantage
of
this
knowledge
by
altering
HTTP
Header
field
might
alter
their
responses
according
to
take
account
their
knowledge
of
the
specific
proxy
behavior.
When
doing
so
it
is
good
practice
to
make
sure
that
the
Internet
content
type
for
a
response
is
correct
for
the
actual
content
(e.g.
a
server
should
not
choose
Content-Type:
application/vnd.wap.xhtml+xml
because
it
suspects
that
proxies
will
not
transform
content
of
this
type,
if
its
content
is
not
valid
XHTML-MP).
If
a
server
has
distinct
representations
that
vary
according
to
the
target
presentation
media
type,
it
can
inhibit
transformation
of
the
response
by
including
a
Cache-Control:
no-transform
directive
(see
D.1.2
Server
Origination
of
Cache-Control:
no-transform
).
In
addition,
in
HTML
content
it
can
indicate
the
medium
for
which
the
representation
is
intended
by
including
a
link
element
identifying
in
its
media
attribute
the
target
presentation
media
types
of
this
representation
and
setting
the
href
attribute
to
"Same-Document
Reference"
(see
[RFC
3986]
section
4.4
)
and
in
particular
an
empty
href
attribute
is
a
"Same
Document
Reference".
In
addition
it
is
good
practice
but
do
we
have
a
reference
for
this
to
include
link
elements
identifying
the
target
presentation
media
types
of
other
available
representations
in
a
similar
manner.
If
content
for
more
than
one
presentation
media
type
is
served
from
the
same
URI,
it
is
better
not
to
use
a
link
element
identifying
the
presentation
media
types
as
the
URI
will
appear
to
be
a
"same
document
reference",
indicating
to
a
client
that
this
representation
is
suitable
for
all
the
named
presentation
media
types.
Instead,
use
a
Vary
HTTP
header
field
indicating
that
the
response
varies
according
to
the
received
User-Agent
HTTP
header.
header
field.
I'm really not sure this is right actually. Think we need to bang on the TAG's door again.
Note:
Some
examples
of
the
use
of
the
link
element
are
included
above
in
C
Example
Transformation
Interactions
.
DOCTYPEs sometimes or usually associated with content intended for mobile delivery
The BPWG believes that POWDER will represent a powerful mechanism by which a server may express transformation preferences. Future work in this area may recommend the use of POWDER to provide a mechanism for origin servers to indicate more precisely which alternatives they have and what transformation they are willing to allow on them, and in addition to provide for Content Transformation proxies to indicate which services they are able to perform.
At
present
HTTP
does
not
provide
a
mechanism
for
communicating
original
header
field
values
(hence
the
use
of
X-Device-
headers
header
fields
as
discussed
under
4.1.5
Alteration
of
HTTP
Header
Field
Values
).
A
number
of
mechanisms
exist
in
HTTP
which
might
be
exploited
given
more
precise
definition
of
their
operation
-
for
example
the
OPTIONS
method
and
the
HTTP
300
(Multiple
Choices)
Status.
The editor acknowledges contributions of various kinds from members of the Mobile Web Best Practices Working Group Content Transformation Task Force .
The editor acknowledges significant written contributions from: