Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Monsur Hossain
On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote:
  The XHR spec defines user credentials as cookies, HTTP authentication,
  and client-side SSL certificates. Its not clear to me what HTTP
  authentication referring to.
 
  I assumed it was referring to the HTTP authentication in RFC 2617, which
  uses the Authorization header. But a quick test shows that arbitrary
  Authorization headers are allowed on CORS requests.
 
  It could also mean the http://username@password:domain.com form of
  authentication (not sure where this is formally defined).
 
  What type of http authentication is the XHR spec referring to?

 User credentials stored by the user agent based on a previous visit to the
 URL.


Ok thanks. I think it would be useful if the HTTP authentication in the
above sentence snippet were either dropped or clarified (The CORS spec also
uses the same sentence).

Authorization is only allowed through CORS if the server opts in, btw.

 These details should become more clear once I turn
 http://wiki.whatwg.org/wiki/Fetch into a proper specification.


 --
 http://annevankesteren.nl/



Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Monsur Hossain
On Tue, Feb 12, 2013 at 1:36 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote:
  On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl
 wrote:
  User credentials stored by the user agent based on a previous visit to
 the
  URL.
 
  Ok thanks. I think it would be useful if the HTTP authentication in the
  above sentence snippet were either dropped or clarified (The CORS spec
 also
  uses the same sentence).

 How is it different from mentioning cookies? It has the same effect, no?


I think what was confusing to me is that the
Access-Control-Allow-Credentials section of the CORS spec indicates that a
true value indicates that the actual request can include user
credentials.

In the case of cookies, both the client's .withCredentials and the server's
Access-Control-Allow-Credentials must be true in order for the user-agent
to return the response to the client.

But in the case of the Authorization header, the server's opt-in
mechanism is Access-Control-Allow-Headers, and has no connection to
Access-Control-Allow-Credentials.

The sentence above reads as if cookies and HTTP Authentication are
both governed by the Access-Control-Allow-Credentials header, which is not
the case in practice.

Note that I am assuming that HTTP Authentication is referring to RFC 2617
and the use of the Authorization header. But the definition for user
credentials in the Terminology section of the CORS spec doesn't say
either way. If this is the case, there should be a reference to RFC 2617 in
the Terminology section (Next to [COOKIES]). And if this is not the
case, there should be more information to disambiguate the term HTTP
Authentication from RFC2617.

Thanks,
Monsur




 --
 http://annevankesteren.nl/



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 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/