New Draft 1x of Guidelines for Web Content Transformation Proxies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

New Draft 1x of Guidelines for Web Content Transformation Proxies

Jo Rabin
Hello Everyone

The moment you have all been waiting for has arrived. Be that as it may,
a new draft is available [1] reflecting the resolutions taken at the F2F
in December [2]. Notes on the changes follow below, diffs from earlier
versions included in the document.

Jo

[1]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/100125.html

[2] http://www.w3.org/2009/12/10-bpwg-minutes.html

RESOLUTION: add a comment to sect 2.2 stating that these are generic
concepts which we choose not to formalise further

(done)

RESOLUTION: Have the document make explicit, if it does not do so
sufficiently already, that moral and legal questions are out of scope
and that this group does not have the authority or expertise to comment
one way or another about setting precedent or authorising any specific
behavior or its absence - nor is such a task feasible in this group.

Added a paragraph under 1.3 Scope

Moral, legal and other similar questions are not in scope of this
document. The BPWG does not have authority or expertise to comment one
way or another about setting precedent or authorising any particular
behavior or its absence.


RESOLUTION: Editor to add further text to scope section along lines of
his earlier minuted statement and Eduardo's recapitulation of it above

Added a paragraph under 1.1 Purpose

It is stressed that this document is unlikely to be the last word on
this topic. As noted below (1.3 Scope) it is out of scope to provide a
thoroughgoing solution to control of transforming proxies, though that
would appear to be needed. It is an attempt to improve a situation at a
point in time where there appears to be disregard of the provisions of
HTTP - and is primarily a reminder and an encouragement to follow those
provisions more closely.

RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should
avoid making repeated requests for the same resource.

RESOLUTION: In addition to above add a note to 4.1.5.1 stating that
while HTTP does not prohibit repetition of GET requests servers find
this troublesome and so it should be avoided

RESOLUTION: Rephrase previous resolution (In addition to above add a
note to 4.1.5.1 stating that while HTTP does not prohibit repetition of
GET requests servers find this troublesome and so it should be avoided)
to talk about places an unnecessary load on the network and server and
not 'troublesome'.

replaced current 4.1.5.1 - "The theoretical idempotency of GET requests
is not always respected by servers. In order, as far as possible, to
avoid misoperation of such content, proxies should avoid issuing
duplicate requests and specifically should not issue duplicate requests
for comparison purposes."

with

While complying with this section 4.1.5 Alteration of HTTP Header Field
Values and 4.2.6 Receipt of Vary HTTP Header Field proxies should avoid
making repeated requests for the same resource.

Note:

While HTTP does not prohibit repetition of GET requests, repeated
requests place an unnecessary load on the network and server.

RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1.

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

Removed: 4.2.1 Applicable Responses

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

RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT
reissue a POST request as it is unsafe (see section 9.1.1 of RFC 2616)"

done

RESOLUTION: add a bullet point to 4.2.9 for "content that is data -
[appendix with list of data mime types]"; application/json ;
application/soap+xml ; application/soap+fastinfoset ;
application/fastsoap ; application/fastinfoset

RESOLUTION: ref. LC-2269, resolve yes, and note that we have added a
bullet point under 4.2.9, an appendix and a reference in 4.1.3 to
address this situation

RESOLUTION: Add the above-mentioned cautionary note to all applicable
appendices

4.1.3 now reads:

Before altering aspects of HTTP requests and responses proxies need to
take account of the fact that HTTP is used as a transport mechanism for
many applications other than "Traditional Browsing". Increasingly
browser based applications involve exchanges of data using
XmlHttpRequest (see 4.2.8 Proxy Decision to Transform) and alteration of
such exchanges is likely to cause misoperation.

added bullet to 4.2.8 (was 4.2.9):

the Content-Type indicates that the content is "data" - some values are
listed in D Internet Content Types associated with Data Content;

Added Appendix

D Internet Content Types associated with Data Content
This list is not exhaustive and is likely to change.

application/jsonapplication/soap+xmlapplication/soap+fastinfosetapplication/fastsoapapplication/fastinfoset

Added cautionary note to Appendices C and E

RESOLUTION: Add a section under J saying that a standard mechanism for
establishing two party consent (that the server must have a possibility
to negotiate or deny HTTPS link rewriting) as discussed under 4.2.9.3 is
needed.

New Appendix: K.5 Explicit Consent
Robust mechanisms are needed for indicating consent to or prohibition of
transformation operations of various kinds, especially HTTPS link
rewriting (see 4.2.8.3 HTTPS Link Rewriting).


RESOLUTION: ref. LC-2317, resolve yes, and add a definition of user
interaction that mentions the communication channel. Exact wording to be
defined by the Editor. This definition should be used in all the
guidelines that mention user interaction similarly to Rotan's proposal
in http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html

Added 2.3 under Terminology

2.3 User Interaction
At various points in this document there is reference to "notifying the
user", "informing the user" - in general making the user aware that a
situation exists or interacting with the user to solicit a choice of
options. The expectation is that such user interaction is conducted in a
way that allows the suer to perceive and interact with such information
or choices in the same way as they interact with the Web sites that they
are visiting.

RESOLUTION: re LC-2318 resolve yes and add text to clarify

Added the following note under 4.1.5

Note:

It is emphasized that requests must not be altered in the presence of
Cache-Control: no-transform as described under 4.1.2 no-transform
directive in Request.

RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part of a
sequence of requests comprising either included resources or linked
resources on the same Web site (see 4.1.5.4)

(sic)

RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of first para to suit

(sic)

RESOLUTION: In re LC-2319, resolve yes and modify the text to say Other
than the modifications required by RFC 2616

4.1.5 "Aside from the usual procedures defined in [RFC 2616 HTTP]
proxies should not ..."

changed to suit.

RESOLUTION: in re LC-2322 - add to 4.2.7, in parentheses, If the user
agent is determined as being "handheld"

done

RESOLUTION: Change "the user agent has features (such as linearization
or zoom) that allow it to present the content unaltered;" to "the user
agent has features (such as linearization or zoom, is a desktop device
using a mobile network for access) that allow it to present the content
without the need for alteration by the proxy;"

done