W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > April 2008

RE: ACTION-739: propose some resolutions on Ajax/XHR requests

From: Sullivan, Bryan <BS3131@att.com>
Date: Wed, 23 Apr 2008 09:24:12 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD09B3F0BC@BD01MSXMB015.US.Cingular.Net>
To: "Francois Daoust" <fd@w3.org>, "public-bpwg-ct" <public-bpwg-ct@w3.org>

+1 to 1.1, 2.1, 2.2, 2.3, 2.4, 2.5

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Francois Daoust
Sent: Wednesday, April 23, 2008 8:59 AM
To: public-bpwg-ct
Subject: ACTION-739: propose some resolutions on Ajax/XHR requests


Roughly a month ago, I raised the problem of Ajax-like calls from within a web page, noting that XHR-like requests cannot be distinguished by the CT-proxy. I summarized my thoughts in:

(linked to ACTION-718, which was, well, around the same as this one...)

After a few discussion, I guess the above-mentioned summary is still accurate. Let me try to summarize our ideas slightly differently. Feel free to correct/complete/totally disagree with the following! As usual, proposed texts are more the generic idea than the precise final text...

1. CT-proxies should not touch pages that contain Ajax calls

PROPOSED RESOLUTION 1.1: in §4.4, add a bullet point to the list of heuristics that says "examination of the content reveals that the page contains client-side scripts that may break if the page gets adapted"


PROPOSED RESOLUTION 1.2: in §4.4, add a guideline that roughly says "A proxy SHOULD NOT transform a page that contains Ajax (or scripting?)"

The presence of scripts in the page surely comes into play when the CT-proxy is thinking hard whether it needs to transform the page or not. 
I would vote for proposed resolution 1.1 as the CT-proxy may know that the user agent doesn't support scripting, and may thus happily remove parts that wouldn't work anyway.

2. XHR exchanges should use a "data" content type such as text/xml or text/plain (as opposed to a "viewable" content type such as text/html, application/xhtml+xml, image/gif, ...) for Ajax calls. CT-proxies must not transform "data" content types

3. A true Web application that uses XHR calls routinely should identify itself as this, and not as the browser itself. In other words, it should change the User-Agent string in the XHR requests it sends, so that CT-proxies know that it's not talking with the browser itself.

4. XHR calls should be made with a "Cache-Control: no-transform" in the HTTP request AND in the HTTP response

These points overlap. If one uses a "data" content-type, then the CT-proxy won't transform the response because it's not one the Content-Type it can transform. If one changes the User-Agent to something else, then the CT-proxy MUST behave transparently as written in §4.1.1 (no "positive" identification of a web browser in that case), and that actually sounds like a good practice to change the User-Agent in Web applications. Adding "Cache-Control: no-transform" directives ensure the request and response remain untouched.

PROPOSED RESOLUTION 2.1: in §4.2, "The server SHOULD add a no-transform directive in responses to Ajax and HTTP-based applications requests"

PROPOSED RESOLUTION 2.2: in §4.2, "Responses to Ajax calls SHOULD use content-types that are not subject to content transformation such as text/xml, text/plain."

PROPOSED RESOLUTION 2.3: in §??? (I don't really know where to put that), "Asynchronous HTTP requests sent from within a Web page (e.g. XHR
calls) SHOULD include a no-transform directive"

PROPOSED RESOLUTION 2.4: in §???, "A HTTP-based application SHOULD identify itself by using a dedicated User-Agent in the HTTP requests it sends. In particular, the User-Agent string SHOULD be changed when using the XHR object to send the requests"

PROPOSED RESOLUTION 2.5: in §4.4, precise the list of content-types that a CT-proxy may transform (there's a pending ACTION-725 on Sean)

We may want to do all of these.
I wonder if it's not too huge a hammer for not-so-big a fly.
I would actually fancy proposals 2.2, 2.4 (which look like "best practices" for developers in a more generic context than CT), and 2.5. 
I'm not really keen on having "no-transform" directives recommended to be added everywhere, and in particular where it's not entirely needed. 
But then, it doesn't make so much harm...

5. When a CT-proxy transforms a response that contains XHR calls, then for consistency reasons, it probably has to transform XHR exchanges as well.

Except this would mean the CT-proxy has to be incredibly smart. It sounds rather hard to guess the developer's intent and transform it on-the-fly transparently.

Anyway, this links to the discussion on consistency that we need to
have: when, if at all, may our guidelines be waived for the sake of consistency?

No proposed resolution for this one, rather a proposed discussion ;-)

Received on Wednesday, 23 April 2008 16:24:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC