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

Thanks Francois for these detailed proposals. I have a bit of a concern that this is getting somewhat over-elaborate and stepping into the area of CT Product design and making some assumptions about the use of XHR that may not be warranted.

I was just looking at http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/ which coincidentally is in last call at the moment, I'd think this topic should be broached with those guys, in fact I pinged Chaals on this topic earlier.

I think the use case which presupposes that XHR is going to be used solely for transfer of data may be flawed. I don't see a particular reason why it should not be used to get an HTML page for display. And there's no strong reason, in my view, to presuppose that the server must always know or care that the request comes from a piece of script.

I'm in favour of including text as suggested by 1.1, though I would expect CT vendors to have something to say about this.

I would prefer to steer clear of assumptions about content types. 2.3 is sufficient to achieve the purpose. So my votes are

+1 to 2.3 - adding the text that if it is important to the application (which it may not be, if it is getting an HTML page)
0 to 2.1 because if a request is received with no-transform then the response SHOULD echo that and the server may not know or care about the fact that this is an Ajax request
-1 to 2.2 a no-transform should be sufficient
-1 to 2.4 as in general this might prevent successful retrieval of an HTML resource from a server that doesn't care that this is an Ajax request
+1 to 2.5 assuming that Sean contributes sensible values! (which I am sure he will of course!) 


Jo

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Sullivan, Bryan
> Sent: 23 April 2008 17:24
> To: Francois Daoust; public-bpwg-ct
> Subject: RE: ACTION-739: propose some resolutions on Ajax/XHR requests
> 
> 
> +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
> 
> 
> Hi!
> 
> 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:
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0028.html
> 
> (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"
> 
> or
> 
> 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 ;-)
> 
> 
> François.
>

Received on Thursday, 24 April 2008 11:25:09 UTC