In the Gecko implementation they aren't. Assuming that you mean when with credentials is set to false?
We also don't reuse keep-alive http connections. / Jonas On May 3, 2013 10:34 AM, "Adam Barth" <[email protected]> wrote: > How does withCredentials interact with TLS client certificates? Ideally > they wouldn't be used either. > > Adam > > > On Friday, May 3, 2013, Anne van Kesteren wrote: > >> I had a discussion with Hallvord on IRC about the exact semantics we >> want for HTTP authentication in the context of CORS (and in particular >> for XMLHttpRequest, though it would also affect e.g. <img >> crossorigin>). >> >> Username/password can be passed via open() or the URL. In that case we >> first check if the server challenges us (do a request without >> Authorization that results in a response with status 401). For CORS, >> we'd return to the caller right there. >> >> If the Authorization header is set via setRequestHeader() we'd treat >> it as any other header. We assume the developer already checked if he >> was challenged or not, etc. >> >> If an Authorization header was cached for the URL in question >> (previous visit) we'd never reuse that under CORS. >> >> This means that withCredentials effectively means "with cookies" (and >> we should have called it that, mea culpa). >> >> I'd be great to know if there's consensus on this. General not caring >> works too. >> >> Context: http://krijnhoetmer.nl/irc-logs/whatwg/20130503#l-318 and >> onwards. >> >> >> -- >> http://annevankesteren.nl/ >> >>
