That is correct.
Thanks
Bin
From: Paul Libbrecht [mailto:p...@hoplahup.net]
Sent: Wednesday, May 08, 2013 1:14 PM
To: HU, BIN
Cc: Hallvord Reiar Michaelsen Steen; Jonas Sicking; Anne van Kesteren; WebApps
WG; WebAppSec WG
Subject: Re: Fetch: HTTP authentication and CORS
On 7 mai 2013, at 02:23
On 7 mai 2013, at 02:23, HU, BIN wrote:
> Because "nonce" is needed to generate the appropriate digest, the 401
> challenge is required.
So the lesson here is: any developer that intends to use authenticated XHR
should always start with an XHR that is a simple ping-like GET, then do the
real th
Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com]
Sent: Monday, May 06, 2013 11:13 AM
To: Jonas Sicking
Cc: Anne van Kesteren; WebApps WG; WebAppSec WG
Subject: Re: Re: Fetch: HTTP authentication and CORS
>> Here I don't agree anymore. If I want to retrieve a HTTP auth-prot
On Mon, May 6, 2013 at 1:39 PM, Hallvord Reiar Michaelsen Steen
wrote:
> (Could we however fix this in CORS so that the WWW-Authenticate header could
> be included in a preflight response where applicable?)
Maybe we should wait for actual complaints about XMLHttpRequest + CORS
lacking integrated
> >> Here I don't agree anymore. If I want to retrieve a HTTP auth-protected
> >> resource
> >> with XHR from a CORS-enabled server, the natural thing to do seems to try
> >> to pass
> >> in the user name and password in the XHR open() call. If the script author
> >> supplied
> >> user/pass and
>> Here I don't agree anymore. If I want to retrieve a HTTP auth-protected
>> resource
>> with XHR from a CORS-enabled server, the natural thing to do seems to try to
>> pass
>> in the user name and password in the XHR open() call. If the script author
>> supplied
>> user/pass and the server sa
On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen
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. > crossorigin>).
>
> So
> 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. crossorigin>).
So me and Anne have been going a bit back and forth on IRC, we agree on some
stu
I really don't know which spec is defining how/when we reuse http
connections. All I know is that we have a pool of open TCP connections
that were used for previous http requests. We don't use that pool when
making credential-less CORS requests. We instead use a separate pool,
specifically for cred
* Jonas Sicking wrote:
>On May 4, 2013 1:29 AM, "Anne van Kesteren" wrote:
>> On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking wrote:
>> > We also don't reuse keep-alive http connections.
>>
>> Are we talking about persistent connections as per
>> http://tools.ietf.org/html/rfc2616#section-8.1 or th
On May 4, 2013 1:29 AM, "Anne van Kesteren" wrote:
>
> On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking wrote:
> > In the Gecko implementation they aren't. Assuming that you mean when
with
> > credentials is set to false?
>
> Right, when it's set to false. What's the normative reference for TLS
> cl
On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking wrote:
> In the Gecko implementation they aren't. Assuming that you mean when with
> credentials is set to false?
Right, when it's set to false. What's the normative reference for TLS
client certificates? https://tools.ietf.org/html/rfc5246#section-7.
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" wrote:
> How does withCredentials interact with TLS client certificates? Ideally
> they wouldn't
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 parti
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. ).
Username/password can be passed via open() or the URL. In that case we
first check if the server chall
15 matches
Mail list logo
