Re: AJAX and CT Proxies

Thanks Sean and Jose,

We roughly agreed during last call that it was probably not worth 
bothering too much about it.
 From a CT perspective, content providers are encouraged to add a 
"Cache-Control: no-transform" directive in XHR calls that they do not 
wish to see transformed.

Still, it would have been great to find a way to make it work with 
existing content, but the point is: there's no way to identify a request 
coming from an XMLHttpRequest object. That's a pity in the sense that it 
sounds reasonable to say that such messages should be left untouched by 
CT-proxies in most cases. Even when using an XHR request to inject some 
HTML code in a page, because the typical use case, as far as I see it, 
will be that *only a portion* of the response will be injected, be it 
the whole <body> section, or, say, the section <div 
id="foo">[...]</div>. If the CT-proxy performs some re-structuring, and 
for instance splits the page into multiple pages, chances are this won't 
work...

I'm not sure what the most flexible approach could be. If I summarize, 
these are the ideas that were raised so far:

1. setting the User-Agent to something that says: "hey, I'm an XHR 
object used in a Web Application, not the browser". It's probably not a 
good idea, typically to fetch (X)HTML pages from servers that adapt 
responses to the client and that therefore need to know what kind of 
user agent is sending the request.

2. amending the User-Agent so that the CT-proxy may tell the request 
originates from an XHR object, while still being transparent for the 
origin server. Again, not sure adding to the User-Agent mess really is a 
good idea.

3. defining an additional header such as "X-Ajax-Engine".

4. setting the Accept header to one that clearly identifies some data 
interchange format such as "application/json". But then, 
"application/xml" is a data interchange format, and may still be used to 
pass on XHTML.

In all cases, this involves a change, and, as said, from a CT-only 
perspective, the "no-transform" directive solves the problem. I am to 
report this case to the Web API working group, to see if such a flag 
could not be worth adding to the XHR document itself... maybe they'll 
think about another better solution!

François.




JOSE MANUEL CANTERA FONSECA wrote:
> Hi,
> 
> Do you really need a new header? If some entity in delivery chain issue a new HTTP request saying
> 
> Accept: application/xml; application/json
> 
> it should be considered as something not to be transcoded. I think this is more consistent with the HTTP protocol design. This approach it is also friendly and consistent with requests coming from J2ME clients, which should also be taken into account.
> 
> If you flag requests coming from the XMLHttpRequest object you will still face the following problem:
> 
> Imagine you are using the XMLHttpRequest mechanism to inject some HTML code in your page. In that case the request comes from the XMLHttpRequest mechanism but a transcoding proxy might be useful to adapt that HTML code that it is the result of the XMLHttpRequest.
> 
> It seems to me that some kind of mechanism based on accept headers could be the most flexible approach
> 
> Best Regards
> 
> ________________________________________
> De: public-bpwg-ct-request@w3.org [public-bpwg-ct-request@w3.org] En nombre de Sean Patterson [SPatterson@Novarra.com]
> Enviado el: miércoles, 30 de abril de 2008 21:27
> Para: public-bpwg-ct
> Asunto: AJAX and CT Proxies
> 
> Re: our discussion of how to detect that a request is really an XHR.
> 
> According to this blog post: http://www.dev411.com/blog/2006/06/30/should-there-be-a-xmlhttprequest-user-agent, at least one of the JS libraries out there (Prototype) uses the X-Requested-With header to indicate that the request is an XHR.  Evidently Dojo and MochiKit don’t send any identifying headers at all, although some people are manually adding some.  The author of the post is proposing an “X-Ajax-Engine” to identify XHR requests.
> 
> This post is from 2006, so I’m not sure what the state of affairs is currently, but I wanted to point out that there seem to be some other people thinking about this issue.
> 
> Sean
> 
> 
>

Received on Monday, 5 May 2008 08:22:49 UTC