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

2012-04-19 Thread Monsur Hossain
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 ann...@opera.comwrote:

 On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain mon...@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/



[CORS] Applying preflight cache to an entire domain?

2012-04-18 Thread Monsur Hossain
Hi there. The CORS spec currently indicates that the preflight cache should
store preflight responses for a particular origin/request url pair. That
means that multiple requests to different urls on the same domain will
always trigger a preflight, even if the preflight response is exactly the
same for those urls. If a server only accepts a set of well defined http
methods and http headers, then issuing the preflight on different requests
is redundant.

I was wondering if there could be a way for the server to indicate what
scope the preflight applies to? For example, the default could still be to
cache per origin/request-url, but maybe the server could set a special
Access-Control-Max-Age-Scope: domain response header to indicate that the
preflight response can be used for any request to the domain. Has anything
like this been considered?

Thanks,
Monsur


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

2012-04-18 Thread Anne van Kesteren
On Tue, 17 Apr 2012 23:35:16 +0200, Monsur Hossain mon...@gmail.com  
wrote:
Hi there. The CORS spec currently indicates that the preflight cache  
should

store preflight responses for a particular origin/request url pair. That
means that multiple requests to different urls on the same domain will
always trigger a preflight, even if the preflight response is exactly the
same for those urls. If a server only accepts a set of well defined http
methods and http headers, then issuing the preflight on different  
requests

is redundant.

I was wondering if there could be a way for the server to indicate what
scope the preflight applies to? For example, the default could still be  
to cache per origin/request-url, but maybe the server could set a special
Access-Control-Max-Age-Scope: domain response header to indicate that  
the preflight response can be used for any request to the domain. Has  
anything like this been considered?


Yes.

http://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html


--
Anne van Kesteren
http://annevankesteren.nl/



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

2012-04-18 Thread Monsur Hossain
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.

Thanks,
Monsur


On Wed, Apr 18, 2012 at 7:16 AM, Anne van Kesteren ann...@opera.com wrote:

 On Tue, 17 Apr 2012 23:35:16 +0200, Monsur Hossain mon...@gmail.com
 wrote:

 Hi there. The CORS spec currently indicates that the preflight cache
 should
 store preflight responses for a particular origin/request url pair. That
 means that multiple requests to different urls on the same domain will
 always trigger a preflight, even if the preflight response is exactly the
 same for those urls. If a server only accepts a set of well defined http
 methods and http headers, then issuing the preflight on different requests
 is redundant.

 I was wondering if there could be a way for the server to indicate what
 scope the preflight applies to? For example, the default could still be
 to cache per origin/request-url, but maybe the server could set a special
 Access-Control-Max-Age-Scope: domain response header to indicate that
 the preflight response can be used for any request to the domain. Has
 anything like this been considered?


 Yes.

 http://lists.w3.org/Archives/**Public/public-appformats/**
 2008May/0039.htmlhttp://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html


 --
 Anne van Kesteren
 http://annevankesteren.nl/



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

2012-04-18 Thread Anne van Kesteren
On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain mon...@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/