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

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

From: Francois Daoust <fd@w3.org>
Date: Wed, 23 Apr 2008 17:58:54 +0200
Message-ID: <480F5CBE.5080209@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>


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 

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

Received on Wednesday, 23 April 2008 15:59:26 UTC

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