Re: [cors] Review

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