Re: IE Team's Proposal for Cross Site Requests

Slap me down if I'm missing something obvious, but doesn't the upcoming 
cross-browser postMessage functionality already give us cross-site XHR? 

A site that want to facilitate CSXHR just hosts a html page that will do 
normal XHR.
This page can be loaded in an iframe and communicates to the parent 
window via postMessage to provide CSXHR.

This means that overly restrictive XSR will just force sites to fall 
back to this scheme.
Unless I'm missing something obvious.

cheers,
Sean


Naive and untested implementation on the site that wants to facilitate 
CSXHR:

http://example.org/xhr.html - loaded into an iframe

<html>
<head>
<script>
document.addEventListener("message", doXHR, true);
function doXHR(event) {
    var  rq = unmunge(event.data);
    var xhr = new XMLHttpRequest;
    xhr.open(rq.method, rq.href, true);
    xhr.onreadystatechange = function() {
       if (xhr.readyState < 4) return;
       if (xhr.status != 200) return;
       event.source.postMessage(munge(rq.method, rq.href, 
serializeHeaders(rq), xhr.responseText);
    }
    xhr.send(rq.data);
}
</script>
</head>
</html>


http://example.org/xhr.js - provides ExampleHttpRequest API

var ExampleHttpRequest = (function() {

var iframe = document.createElement("iframe");
iframe.src = "http://example.org/xhr.html";
iframe.style.height = "0px";
document.body.appendChild(iframe);

var ExampleHttpRequest = function() {};

ExampleHttpRequest.prototype.open = function(method, href) {
    this.method = method;
    this.href = href;
    this.headers = {};
}

ExampleHttpRequest.prototype.send = function(data) {
    document.addEventListener("message", callbackXHR, false);
    var messageData = munge(this.method, this.href, 
serializeHeaders(this), this.data);
    iframe.postMessage(messageData);
}

function callbackXHR(event) {
    var result = unmunge(event.data);
    // to drunk to fill in the rest
}

return ExampleHttpRequest;

})();



Kris Zyp wrote:
>
>> If XDR only supports GET and POST, it encourages sites to use POST to
>> implement delete functionality and abuse the HTTP protocol because that
>> is the only way they can get the functionality they desire to work.
>> Basically, you’re boycotting REST in favour of SOAP.
> I completely agree, it shouldn't be the place of the browser to 
> dictate that developers they must use SOAP style instead of REST, and 
> cripple the features of HTTP. The full features of REST (PUT and 
> DELETE) weren't available in traditional web apps, but with Ajax, I 
> belive REST techniques are rapidly growing in popularity, and will be 
> particularly useful in cross-site scenarios because authors can 
> leverage HTTP semantics to indicate meaning with different 
> consumers/providers. I believe the same potential is possible with 
> Accept headers, especially in the cross-domain world. Accept headers 
> are not heavily used right now because in the dominantly same-origin 
> request world because developers usually know a priori what content 
> type is needed. On the otherhand, with cross-site web services, 
> different consumers may desire different formats, and the Accept 
> parameters could have awesome potential for allowing developers to 
> request data in a desired format in well-understood manner. How 
> foolish it would be to disable these features in the arena where it 
> would have the most opportunity for benefit.
> I believe the full potential of HTTP has a great opportunity to be 
> fully realized in the cross-site world where leveraging well-defined 
> broadly understood HTTP features like REST semantics, 
> content-negotiation, partial content transfer, etc. could vastly 
> improve interoperability, by allowing consumers and providers to 
> communicate with a rich set of well-defined capabilities. Crippling 
> HTTP will force developers to use work-arounds which will only 
> decrease interoperability and will ultimately cause increased use of 
> hacks which will envitably subvert security rather than benefiting it. 
> Trying to create a simpler more restrictive form of security does not 
> mean things will be more secure. Developers use of cross-site scripts 
> with callbacks to get cross-site data is great example of how an 
> excessively simple security model has resulted in developers being 
> forced to use dangerous methods to accomplish their goals.
> Thanks,
> Kris
>
>

Received on Sunday, 16 March 2008 17:50:25 UTC