The moment you have all been waiting for has arrived. Be that as it may,
a new draft is available  reflecting the resolutions taken at the F2F
in December . Notes on the changes follow below, diffs from earlier
versions included in the document.
RESOLUTION: add a comment to sect 2.2 stating that these are generic
concepts which we choose not to formalise further
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 126.96.36.199 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 188.8.131.52 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
replaced current 184.108.40.206 - "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."
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.
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,
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 220.127.116.11 with "A proxy MUST NOT
reissue a POST request as it is unsafe (see section 9.1.1 of RFC 2616)"
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
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;
D Internet Content Types associated with Data Content
This list is not exhaustive and is likely to change.
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 18.104.22.168 is
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 22.214.171.124 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
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
RESOLUTION: re LC-2318 resolve yes and add text to clarify
Added the following note under 4.1.5
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 126.96.36.199)
RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of first para to suit
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"
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;"
|Free forum by Nabble||Edit this page|