W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

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

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 12 May 2008 15:51:27 +0200
To: Francois Daoust <fd@w3.org>
Cc: public-webapi@w3.org
Message-ID: <0vhg24d7keo6s39ki1s8q30t7sc157vqru@hive.bjoern.hoehrmann.de>

* 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.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 12 May 2008 13:52:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC