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

Jo Rabin wrote:
> 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.

Actually, I even have the feeling that this is slightly stepping 
_outside_ the area of CT.

> 
> 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.

Yes. Excellent idea. Identifying a request coming from an XHR object 
should indeed not be a need specific to CT.


> 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.

And you were the one wondering whether there would be any other use than 
that of "data" exchanges ;-)
My first thought was: if the XHR call retrieves an HTML page for 
display, why prevent the transformation of the page?
I guess the answer is that the call would probably update the DOM tree 
with a part of the HTML page, and thus needs to parse the original page. 
It tastes like data being exchanged, but it's not really data, so the 
use of an HTML-like content-type is justified...


> 
> 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

In most cases, the origin server control both ends (server and client 
that sends the Ajax requests), as XHR calls (for the time being, that 
is) can't do cross-site requests. But then, you're absolutely right, for 
an HTML resource, the server has to know which device sent the request 
to return the resource adapted to it. So we should not "change" the 
User-Agent! We may still want to "complete" it but that would mean that 
the change would have to be transparent for the origin server whereas it 
should switch off the CT-proxy, which is possible, but sounds like an 
ugly hack.

For the sake of clarity, I'd say the way 2.2 is formulated is not the 
way I intended it. It would better have been:
"If your intention is to exchange data, don't wrap it in an HTML-like 
page", but that doesn't change the conclusion:
2.2 would better be a generic and obvious good practice: if you exchange 
data, use data content-types. Nothing to do with CT. So nothing to do here.
2.4 would only work for applications that exchange data, and again, 
doesn't have that much to do with CT, and would better be listed in 
another document: if you're only using the browser's capabilities to 
exchange data, change the User-Agent.

I'm still not a huge fan of the addition of the no-transform directive, 
but I don't see any other choices left.
I'd say that in the final wording for 2.3, we could still mention the 
fact that pure data content-types won't be transformed by CT-proxies, so 
the addition of a "no-transform" directive is not always needed. 
Probably not worth mentioning though as it will be a consequence of the 
list of content-types subject to transformation.

François.


> +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 13:27:15 UTC