Re: [cors] Review

The description below is mostly correct, but the issue is with
updates, not fetches. A GET does not require a pre-flight under CORS,
but a PUT does and a POST probably does. So for example, cross-domain
use of a CouchDB database will result in doubled latency and network
requests in all data update scenarios.

"HTTP Document API - Couchdb Wiki"
http://wiki.apache.org/couchdb/HTTP_Document_API

Also note the "probably" for POST requests. CORS encourages web-apps
to label all POST entities as "text/plain".

Mnot also raised additional issues in his most recent CORS review.

--Tyler

On Wed, Jun 17, 2009 at 1:29 PM, Mark S. Miller<erights@google.com> wrote:
> On Wed, Jun 17, 2009 at 1:01 PM, Anne van Kesteren <annevk@opera.com> wrote:
>>
>> On Wed, 17 Jun 2009 19:45:54 +0200, Tyler Close <tyler.close@gmail.com>
>> wrote:
>>>
>>> If this technique can in practice provide adequate protection, it is a
>>> much better solution than CORS, which undermines HTTP and webarch in a
>>> number of ways (all discussed previously and again raised by mnot).
>>
>> I do not think CORS undermines HTTP or webarch.
>
> Let me see if I understand mnot's criticism.
>
> The current CORS proposal requires a preflight per URL, and that therefore
> can only be cached per URL.
>
> HTTP / REST / webarch are premised on distinct resources being named by
> distinct URLs.
>
> A RESTful server serving a large number of linked small resources may
> therefore serve a large number of URLs, each of which may only be fetched
> once in typical use.
>
> A browser-based app, navigating among these resources by following their
> links to each other is limited (ignoring fancy protocols that go beyond HTTP
> recommendations) to one level of traversal per round trip.
>
> The contrasting style represented by SOAP uses a URL to designate a large
> aggregate of resources, and uses other information in the payload to
> determine which of these resources is being addressed. This is considered to
> be counter to HTTP / REST / webarch recommendations.
>
> Under CORS, a browser-based app navigating a cross-origin RESTful service
> will typically be limited to one level of traversal per sequential pair of
> rond trips. In the peformance approximation of "latency is everything", this
> doubles the cost of following HTTP / REST / webarch recommendations.
>
> Under CORS, a SOAP-like service would pay no such penalty, since the
> preflight cache would almost always hit. These comparative costs would
> create an irresistable incentive to violate HTTP / REST / webarch
> recommentations.
>
> Mnot, do I have this right?
>
> --
>    Cheers,
>    --MarkM
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 17 June 2009 20:45:50 UTC