Re: [XHR] withCredentials and HTTP authentication
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
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?
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?
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?
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/
