BTW - have you considered allowing setting withCredentials to "false" for same-origin resources?
As-is, the author may not expect what happens if she sets withCredentials to false, makes a cross-origin request, and the remote server redirects to a same-origin URL. Now cookies will be sent to that resource, as far as I can tell. This is unexpected, and may well give authors a false sense of security, believing they have safeguarded against certain CSRF / confused deputy attacks when they haven't. The answer is of course creating an anonymous request instead, but the example illustrates the potential for confusion when we have two apparently similar ways to achieve a "don't send credentials " state in the API. If withCredentials were a tri-state flag, where unset would default to false on cross-origin and true on same-origin requests, I think this would be much clearer. (You might think changing this is too late, but the only effect of the change would be respecting instead if ignoring an explicit withCredentials=false for same-origin requests. IMHO impact on existing content is unlikely). Now, apologies if this, too, has been discussed already. Most of the prior discussion I am aware of is found in this thread Anne made me aware of: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg171 plus some related to CORS issue 108. Hallvord Den 17. mai 2013 kl. 11:53 skrev Anne van Kesteren <[email protected]>: > On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen > <[email protected]> wrote: >> Anonymous mode still seems like useless complexity to me, so I'm still in >> favour of dropping it. > > Right. I don't really get the feeling you're considering the arguments > carefully and since nobody else seems to be participating here (much > like before) I'm not sure this is a good use of our time. > > > -- > http://annevankesteren.nl/
