There are 20 comments (sorted by their types, and the section they are about).
substantive comments
Comment LC-2289
Commenter: Luca Passani <passani@eunet.no> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :> "Is the current version of the document good enough to ship?"
No, it is not.
- it is not good enough for mobile developers who desperatly need a
solid platform to build their apps (and not a spec that can be leveraged
by someone somewhere to justify messing with HTTP in unforeseeable ways)
- it is not good enough for content owners (who don't want to have their
content messed with)
- it is not good enough for telcos which want to deploy transcoders
(there are no clear rules about what they should and should not do to
avoid liability when they transcode other companies' content)
The only people who CTG is good for at the moment are transcoder
vendors, who can refer to a document which is ambiguous enough that they
can read whatever they want into it and wrap their products into a
shroud of W3C legitimacy.
Luca
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added16
Resolution: It is not the intention of this document to address legal, moral or liability issues. We do not think that this document is to be viewed as the final word on the subject, though we think it is a valuable contribution. (Please make sure the resolution is adapted for public consumption)
Comment LC-2316
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.1 Applicable HTTP Methods
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 4.1.1 "Proxies should not intervene in methods other than GET, POST, HEAD." "Intervene" is vague here; does it mean that they're not allowed to change the requests, but are allowed to change the responses to them? Or they're not allowed to transform neither the request nor the response?
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added02
Resolution: We agree and have removed the restriction on specific HTTP methods in 4.1.1 and 4.2.1. It was unnecessary to mention this in this document which is scoped to traditional Web browsing. (Please make sure the resolution is adapted for public consumption)
Comment LC-2317
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.4 Serving Cached Responses
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 4.1.4 "so should notify the user that this is the case" -- how? Using a Warning header? Are they required to populate the Age header, so that the user can calculate whether it's stale themselves?
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added07
Resolution: We agree and have added a definition of user interaction that details the communication channel that must be used. We have re-worded the guidelines that refer to user interaction as a consequence. (Please make sure the resolution is adapted for public consumption)
Comment LC-2320
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.5 Alteration of HTTP Header Field Values
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 4.1.5 "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." This seems like a hole that a proxy vendor can drive a truck through... are you serious?
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added09
Resolution: We agree and have removed mentions of "technically infeasible" and "preserves consistency of user experience". The bullet point now reads: "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)". Section 4.1.5.4 contains the normative guidelines relevant to this case. (Please make sure the resolution is adapted for public consumption)
Comment LC-2321
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.5 Alteration of HTTP Header Field Values
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 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."
Existing proxies can and do already retry GETs; I'm not sure who you're trying to protect here.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added01
Resolution: We have removed the mention of the "theoretical idempotency of GET requests" and clarified the text in relation with the mechanisms described in 4.1.5 and 4.2.6. However, we still advise to reduce the number of requests sent for the same resource where possible. (Please make sure the resolution is adapted for public consumption)
Comment LC-2324
Commenter: Luca Passani <passani@eunet.no> (archived message ) Context: 4.1.5.1 Content Tasting
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Francois Daoust wrote:
> For clarification, the guidelines do not build on the assumption that
> GET is not safe.
>
> The mechanism described by Luca is actually recommended by the
> guidelines: send a GET with original headers, then send a request with
> modified headers if the first response is a "request unacceptable"
> response.
Francois, this is not what I meant. What I meant is "content tasting".
Proxies should send a GET with original headers and if they get a
response (which they probably will), they should smell the response and
figure out whether that content may be good enough for mobile (and err
on the side of assuming it is). If the content is likely to be OK for a
mobile device, no transcoding should take place at all.
This is explicitly ruled out by 4.1.5.1:
http://www.w3.org/TR/ct-guidelines/#sec-content-tasting
"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."
There was no reason to add this part, except, as I mentioned in my first
message, to help novarra, whose transcoder does not behave this way.
Luca
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added01
Resolution: We agree and have removed the inconsistency in 4.1.5.1. Content tasting whereby the unaltered request is sent first is encouraged by the guidelines. (Please make sure the resolution is adapted for public consumption)
Comment LC-2327
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.5.2 Avoiding "Request Unacceptable" Responses
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :e.g. it allows retrying a POST request upon a 406, even though this isn't allowed in HTTP.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added03
Resolution: We agree and have removed the exception to the rule in 4.1.5.2. The section now refers to section 9.1.1 of RFC2616. (Please make sure the resolution is adapted for public consumption)
Comment LC-2328
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.2.3 Receipt of Cache-Control: no-transform
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :It effectively allows proxies to ignore no-transform, if they really want to.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added10
Resolution: We agree and have removed the exception to the rule in 4.2.3. The guidelines do not allow proxies to ignore no-transform anymore. (Please make sure the resolution is adapted for public consumption)
Comment LC-2329
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.2.5 Server Rejection of HTTP Request
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :It blurs the semantics of a 200 response based upon its content.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added11
Resolution: We take your point but pragmatically speaking the distinction is blurred by Web site owners. (Please make sure the resolution is adapted for public consumption)
Comment LC-2322
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.2.7 Link to "handheld" Representation
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 4.2.7 Link to "handheld" representation -- you're requiring proxies to "process" (whatever that means) handheld links, even if the client isn't handheld?
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added13
Resolution: We have clarified the guideline to apply only to user agents that are "handheld". (Please make sure the resolution is adapted for public consumption)
Comment LC-2269
Commenter: Eduardo Casais <casays@yahoo.com> (archived message ) Context: 4.2.9 Proxy Decision to Transform
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :A proposal to amend the CTG with the objective of avoiding deleterious interferences
of transformation proxies with certain non-browsing applications.
I. CONTEXT
Developers are deploying applications that go beyond traditional browsing, by taking
advantage of powerful devices and advanced user agents.
The cluster of technologies identified as AJAX (AJAX, JSON, XMLHttpRequest) has
already established itself in the mobile world. Web Services (SOAP, WSDL) is another
one that, while still in its infancy regarding mobile phones, is already available
on laptops with wireless connections.
The W3C acknowledges the importance of emerging applications based on such
technologies for the mobile world, notably with respect to AJAX in its "Mobile Web
Applications Best Practices" (currently under review).
Section 4.1.3 of the CTG warns about potentially serious problems when content
transformation proxies alter HTTP transactions making up the communication flow
between non-traditional browsing clients and servers. However, the CTG do not
provide any guidance as to the avoidance of such misoperations.
In the field, application developers have been facing aggressively configured CT
proxies that interfer with AJAX communications -- on the basis that the content
transmitted over HTTP does not fit into pre-defined categories of "mobile browsing",
is henceforth viewed as "desktop content", and then thoroughly garbled by
misdirected transformations.
II. PROPOSAL
The following text is included in the normative part of the document:
"A content transformation proxy MUST handle HTTP requests from a terminal, and
corresponding responses to them, transparently whenever the HTTP transaction
conveys a payload advertised as one of the following MIME types:
application/json
application/xml
text/xml
application/soap+xml
application/soap+fastinfoset
application/fastsoap
application/fastinfoset
These MIME types distinguish traditional browsing transactions from AJAX
communications and messages in Web Services."
III. RATIONALE
a) Compliance with standards
The listed MIME types are specified by the IETF or the ITU-T:
application/json in RFC4627;
application/xml and text/xml in RFC3023;
application/soap+xml in RFC3902;
application/fastinfoset in ITU-T Rec. X.891 | ISO/IEC 24824-1;
application/soap+fastinfoset and application/fastsoap in ITU-T Rec. X.892 | ISO/IEC
24824-2.
All are registered at IANA (see http://www.iana.org/assignments/media-types).
b) Application scope
The listed MIME types are conclusively used for non-traditional browsing applications.
application/json, application/soap+xml, application/soap+fastinfoset are exclusively
associated with AJAX, resp. Web Services applications.
The type application/soap+xml is recommended by the W3C for marshalling messages
between Web Service entities:
SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
W3C Recommendation 27 April 2007
http://www.w3.org/TR/2007/REC-soap12-part1-20070427
The W3C further mandates support for this MIME type in:
SOAP Version 1.2 Part 2: Adjuncts (Second Edition)
W3C Recommendation 27 April 2007
http://www.w3.org/TR/2007/REC-soap12-part2-20070427
MIME types application/xml and text/xml are preferred by the W3C for information
exchange during an AJAX session in its on-going standardization of XMLHttpRequest:
XMLHttpRequest
W3C Working Draft 20 August 2009
http://www.w3.org/TR/XMLHttpRequest
XMLHttpRequest Level 2
W3C Working Draft 20 August 2009
http://www.w3.org/TR/XMLHttpRequest2
These two MIME types are also those that application developers should or even must
use, according to the documentation of several manufacturers of client software.
c) Overlap with browsing
The listed MIME types are neither used, nor recommended for traditional browsing;
hence, there is no ambiguity as to the non-applicability of transformations on HTTP
transactions that deal with content of those types.
d) Generality
An alternative is to insert a "no-transform" directive in the HTTP transactions of
non-traditional browsing applications. This is however not always possible because
the AJAX or SOAP modules may be compiled packages that cannot be configured or
modified by the developer (whether in the terminal user agent or on the server Web
platform), or that are not under the control of the developer (terminal: configuration
only possible manually by users themselves, or only by the operator; server: platform
under the control of the ISP in a shared hosting environment).
E.Casais
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added04
Resolution: We agree and have added the list of data mime types in an appendix referenced from a bullet point in the list of rules for which proxies should not transform the response. "application/xml" and "text/xml" were removed from the list as they may be used to serve XHTML content (although that is not recommended).
Additionally, section 4.1.3 was completed to point out that more and more browser based applications involve exchanges of data using XmlHttpRequest and that alteration of such exchanges is likely to cause misoperation. (Please make sure the resolution is adapted for public consumption)
Comment LC-2360
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: 4.2.9.1 Alteration of Response
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :4.2.9.1 #2: The altered content should validate to an appropriate
published formal grammar and be well-formed. Validation might be a
problem for an accessibility transcoding solution. Validation is not
part of WCAG 2.0 because sometimes adding in stuff that's not in the DTD
can make something more accessible (like ARIA for example). Note that
this is a "should", not a "must".
Related issues: (space separated ids)
WG Notes: http://www.w3.org/2010/01/12-bpwg-minutes.html#item03
In respect of LC-2360, resolve no. The document specifies a SHOULD for validation, so this should not be an issue, we think
Resolution: We agree that there are cases when validation should not have to be enforced and note that this is precisely why the guideline is a "should": transcoding proxies may need to produce content that does not validate against a formal grammar "but the full implications must be understood and carefully weighed" (quoted from the definition of "should" in RFC 2119).
(Please make sure the resolution is adapted for public consumption)
Comment LC-2270
Commenter: Eduardo Casais <casays@yahoo.com> (archived message ) Context: 4.2.9.3 HTTPS Link Rewriting
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :A proposal to endow servers with the possibility to protect their HTTPS services from
URL rewriting.
I.   CONTEXT
The CTG allows proxies to rewrite URL, including those indicating that the
communication between terminal and server is to be established as an end-to-end
connection over TLS/SSL.
The W3C acknowledges the serious security concerns that arise from such rewriting
operations, but does not provide any mechanism for servers to protect their services
from the corresponding security risks.
HTTPS URL rewriting has perhaps been the more contentious issue of the CTG so far,
and has serious consequences on the credibility of the mobile Web for advanced
applications requiring privacy, payment security; it opens up a can of worm regarding
liability and certification of mobile e-commerce solutions.
II.   PROPOSAL
The following text is to be added to a new section 4.2.9.4 of the CTG:
"Proxies must provide a means for servers to express preferences for inhibiting
HTTPS URL rewriting regardless of the preferences expressed by the user.
Those preferences must be maintained on a Web site by Web site basis."
III.   RATIONALE
The proposal addresses the issues raised by HTTPS URL rewriting, without imposing
a specific mode of implementation. As such, it does not prescribe (non-standard)
mechanisms, nor introduces new technology into the CTG, but only sets formal
requirements as to their end-effect.
I re-establishes the consistency between on the one hand the facts that
a) the original decision to establish HTTPS connections lies within the server;
b) the knowledge about what level of security is appropriate for a Web application
lies on the server side;
c) problems of liability, customer support, and commercial reputation fall back onto
the server;
and, on the other hand, the facts that
d) the server is not given any decision power as to whether end-to-end security is to
be respected or not;
e) only the end-user, who does not possess all required knowledge to assess the
situation, is given mechanisms in the current CTG to prevent transformations on site
by site basis.
It takes into account the fact that none of the available mechanisms utilized by
well-behaved proxies is reliable when it comes for a server to detecting whether an
HTTPS URL rewriting has taken place or not. In particular, "via" fields may or may
not be retransmitted integrally by some HTTP standards-compliant proxies, as indicated
in section 4.1.6.1 of the CTG.
It is in line with the practice in some countries, where operators have set up
mechanisms such as "white lists" to exclude financial institutes from HTTPS URL
rewriting. This demonstrates that, notwithstanding whatever is stated about the
relevance of rewriting HTTPS links, the consequences of such operations are taken
quite seriously.
E.Casais
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added05
Resolution: We agree that this is important but note that no standard mechanism can be used for establishing two party consent at the time of writing this document. A section was added in the Scope for Future Work appendix to point out that such standard mechanism is needed. (Please make sure the resolution is adapted for public consumption)
editorial comments
Comment LC-2358
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :>From the introductory text and clauses such as 4.2.7 through 4.2.9, it
is clear that this is targeted at proxies that are transcoding content
for mobile devices yet the title sounds like it's targeted at any kind
of transformation proxy. Suggest changing the title to more accurately
reflect the narrower scope.
Related issues: (space separated ids)
WG Notes: In respect of LC-2358 resolve no, we understand the point but have debated this at length previously and this is the best title we could think of.
Resolution: We have debated about the title at length previously and this is the best title we could think of that remains in the title category and does not degenerate into a full abstract. We think that the abstract section precises the narrower scope under which the guidelines are to be read. (Please make sure the resolution is adapted for public consumption)
Comment LC-2318
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.5 Alteration of HTTP Header Field Values
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 4.1.5 It needs to be explicitly pointed out here that the modifications listed are not allowed when CC: no-transform is present in the request. Otherwise, the relative precedence of the requirements in the document is too imprecise.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added08
Resolution: We agree and have clarified the text. (Please make sure the resolution is adapted for public consumption)
Comment LC-2319
Commenter: Mark Nottingham <mnot@mnot.net> (archived message ) Context: 4.1.5 Alteration of HTTP Header Field Values
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :* 4.1.5 "Aside from the usual procedures defined in [RFC 2616 HTTP] proxies should not modify the values" -- I have a hard time parsing this. Do you mean "In addition to the requirements of [RFC2616]..." ?
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added12
Resolution: We agree and have reworded the text to say "Other than the modifications required by RFC2616" (Please make sure the resolution is adapted for public consumption)
Comment LC-2359
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: 4.2.3 Receipt of Cache-Control: no-transform
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :4.2.3: If a website contains a "Cache-Control: no transform" directive,
proxies must NOT alter the content. Would this be a problem for a
proxy-based accessibility transcoding solution?
Related issues: (space separated ids)
WG Notes: RESOLUTION: In respect of LC-2359, resolve partial. We agree that it is heavy handed but it is the only mechanism provided by RFC 2616. We will amplify the note regarding possible damaging effects of using it - at present this notes that WAP gateways may mis-operate in its presence
Resolution: We agree that the "Cache-Control: no transform" directive is heavy handed but it is the only mechanism provided by RFC 2616. We have amplified the note in Appendix I.1.3 (the appendix provides informative guidance for Origin Servers and this section relates to the use of the "Cache-Control: no-transform" directive) to state that this directive can also disrupt the behavior of a proxy based accessibility solution. (Please make sure the resolution is adapted for public consumption)
Comment LC-2268
Commenter: Thomas Roessler <tlr@w3.org> (archived message ) Context: 4.2.9 Proxy Decision to Transform
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :As a final comment, in the check list at the top of section 4.9.2, the
"other factors" laudably include:
> "the user agent has features (such as linearization or zoom) that
> allow it to present the content unaltered;"
Given that content transformation proxies at times depend on the
network that is used to access a resource, it might also be worthwhile
calling out the use of a "desktop" browser over a mobile network as a
case that proxies should take into account.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added14
Resolution: We agree and have updated the bullet point in section 4.2.9 to mention that use case. (Please make sure the resolution is adapted for public consumption)
Comment LC-2267
Commenter: Thomas Roessler <tlr@w3.org> (archived message ) Context: 4.2.9.2 Link Rewriting
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :From a quick review, section 4.2.9.3 looks vastly improved. I'll
solicit the WSC WG's opinions on the changed version; speaking
personally, I'm happy with the current text.
I would like to call out a specific point in 4.2.9.2:
> Proxies must preserve security between requests for domains that are
> not same-origin in respect of cookies and scripts.
It is probably worthwhile to call out in non-normative security
considerations what that actually means -- namely, fairly heavy
rewriting of scripts along the lines of what CaJa does, and rewriting
of cookies to emulate the behavior that a browser would otherwise show.
Related issues: (space separated ids)
WG Notes: Resolution:
http://www.w3.org/2009/12/10-bpwg-minutes.html#added15
Resolution: We take your point, but this document does not specify the internal operation of transforming proxies so we find it hard to think of anything useful to say. (Please make sure the resolution is adapted for public consumption)
Add a comment .