Re: [CORS] Applying preflight cache to an entire domain?

Thanks for the clarification, that makes sense.

A little background on why I'm thinking about this. I've been investigating
CORS performance on mobile. Mobile is a great use case for CORS since it is
mostly guaranteed to be supported (at least on iOS and Android). However,
the cost of making two HTTP requests per logical request can be expensive,
especially in a mobile environment.

The preflight cache is keyed on the origin/url pair. Furthermore, Chrome
includes a max-preflight time on 5 minutes (not sure if other browsers do
the same). So in an ideal scenario, the browser will be making one
preflight request every 5 minutes.

That doesn't sound so bad, but consider a typical RESTful API, where each
resource is represented by a different url. The preflight cache will yield
a cache hit in very narrow situations (perhaps while updating the same
resource over and over again, or polling a particular endpoint).

So I'm concerned that the cache-hit ratio in real world applications will
actually be quite low. It would be nice to have some sort of solution to
this.

Thanks,
Monsur


On Wed, Apr 18, 2012 at 11:50 AM, Anne van Kesteren <annevk@opera.com>wrote:

> On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain <monsur@gmail.com>
> wrote:
>
>> Ah thank you! I agree that url canonicalization is a difficult issue to
>> solve. FWIW, I was envisioning something much simpler. The CORS spec makes
>> it clear that cache lookup should be done by origin and request url. So
>> instead of specifying a url to this Access-Control-Policy-Path header, it
>> would be just one of three values:
>>
>>   - "url" - (default behavior) Cache lookup is done by origin and request
>>
>>   url, as the spec indicates now
>>   - "origin" - Cache lookup is done by origin only. Preflight response
>>
>>   applies to any request from this origin.
>>   - "any" - Cache lookup applies to *any* origin making requests to the
>>
>>   domain.
>>
>> This would fit in with the current preflight caching model while still
>> allowing some flexibility to servers implementing CORS.
>>
>
> The reason why we wanted it scoped was because people had concerns about
> giving any URL on a server control over which other resources would end up
> being shared. The scenarios typically involved large organizations with
> many different teams operating on a single origin. If one of those teams
> thinks sharing with everyone is fine, the rest can be comprised. And such a
> mistake is rather easy to make.
>
> Another general concern that has been frequently raised and why the
> specification has so many flags for enabling additional features such as
> headers and methods, is that people easily shoot themselves in the foot.
> Your proposal makes it rather easy for them to shoot themselves in the foot.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>