W3C home > Mailing lists > Public > public-appformats@w3.org > March 2008

Re: IE Team's Proposal for Cross Site Requests

From: Kris Zyp <kris@sitepen.com>
Date: Sat, 15 Mar 2008 21:49:03 -0600
Message-ID: <02e401c88718$aea4cd20$0500a8c0@kris>
To: "Laurens Holst" <lholst@students.cs.uu.nl>, "Eric Lawrence" <ericlaw@exchange.microsoft.com>
Cc: "Web API WG \(public\)" <public-webapi@w3.org>, <public-appformats@w3.org>, "Sunava Dutta" <sunavad@windows.microsoft.com>, "Chris Wilson" <Chris.Wilson@microsoft.com>, "Zhenbin Xu" <zhenbinx@windows.microsoft.com>, "Gideon Cohn" <gidco@windows.microsoft.com>, "Sharath Udupa" <Sharath.Udupa@microsoft.com>, "Doug Stamper" <dstamper@exchange.microsoft.com>, "Marc Silbey" <marcsil@windows.microsoft.com>

> 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.
Received on Sunday, 16 March 2008 03:50:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:22 UTC