Re: [XHR] No way to tell a request originates from an XHR object

Bjoern Hoehrmann wrote:
> * Francois Daoust wrote:
>> In the context of content transformation that is a problem because such 
>> HTTP messages should be passed untouched by the content transformation 
>> proxies: an XHR call involves that some client code will be run on 
>> receipt of the response, so any transformation is likely to break the 
>> content delivered by the device.
> 
>> We were wondering if that use case would not meet other similar use 
>> cases in other areas that would require an easy way to tell that a 
>> request originates from an XHR object. Possible solutions:
>> 	1. amending the User-Agent string to include an "XHR"-like string somewhere
>> 	2. defining an additional header such as "X-Ajax-Engine" [2]
>> 	... and hopefully better solutions we haven't thought about.
> 
> It is usually better to indicate your requirements instead of what soft-
> ware you are using; for example, instead of XHR you might be using the
> WebClient in Microsoft's SilverLight, or you might be using no Ajax en-
> gine at all. So here you would instead indicate that the response should
> be as if it had Cache-Control: no-transform set.
> 
> I will also note that just because the request is initiated by a browser
> that does not mean there is no script that breaks on transformed content
> (whether you load some XHTML document with an <iframe> or XHR is not all
> that relevant). You will ultimately have to rely on some cooperation on
> part of the author, or transform content only very conservatively.

Yeah, I think this is better addressed in a spec for mobile UAs instead. 
Such a spec could recommend that UAs add a header, like the one Bjoern 
is proposing, in certain situations. Such as when XHR requests are made, 
or when XBL documents are fetched, or when document.load is used, etc.

But like others, I would expect a lot of sites to break if 
transformations were done to them without their cooperation. This is why 
we have greacemonkey scripts as extensions, and not built in by default :)

/ Jonas

Received on Tuesday, 13 May 2008 01:19:05 UTC