Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of bowserj@gmail.com designates
 209.85.212.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOBL_k6k1aenU_QA=Omo-ZsN9WvWXUsJMu6DLoYj5csJOD4EfA@mail.gmail.com>
References: 
 <CAE6O_-aLuE=uEdJAoEQ21G=CK14GPzinMehQ6UaYEt39jgTtyg@mail.gmail.com>
	<CAOBL_k6k1aenU_QA=Omo-ZsN9WvWXUsJMu6DLoYj5csJOD4EfA@mail.gmail.com>
Date: Thu, 2 May 2013 16:56:12 -0700
Message-ID: 
 <CAOBL_k5D-NaiG7J_t=E+RVR1Zu460XdHAwp6Mmdeso=zGaYjgQ@mail.gmail.com>
Subject: Re: [iOS] XmlHttpRequest and 401 Unauthorized
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Applicable Android counterpart: https://issues.apache.org/jira/browse/CB-2962

On Thu, May 2, 2013 at 4:54 PM, Joe Bowser <bowserj@gmail.com> wrote:
> I think this is a webkit thing, since Android has the same problem.
> We have some authorization code, but I'm pretty certain that it
> doesn't do the right thing.  That being said, I have no idea what the
> right thing is.
>
> On Thu, May 2, 2013 at 4:52 PM, Shazron <shazron@gmail.com> wrote:
>> To summarize, this is an iOS thing, not a Cordova thing. We are just trying
>> to work around it.
>>
>> JIRA issue:
>> https://issues.apache.org/jira/browse/CB-2415
>>
>> The proposed workaround is intrusive in that we basically need to create
>> our own NSURLConnection for each shouldStartLoadRequest call, and handle
>> the authentication challenge by letting it proceed (thus the call does not
>> "hang").
>>
>> I'm not sure of the impact of this, but it touches every call.
>>
>> The only workaround in JavaScript is to do a setTimeout for the call, but
>> then we never get a 401 status code of course.
>>
>> Thoughts?