Re: Fetch: HTTP authentication and CORS

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" <w3c@adambarth.com> 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/
>>
>>