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
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
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).
So me and Anne have been going a bit back and forth on IRC, we agree on some
On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
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 says 401 on a
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 says 401
On Mon, May 6, 2013 at 1:39 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
the appropriate digest, the 401 challenge
is required.
Hope it helps
Bin
-Original Message-
From: 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
On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking jo...@sicking.cc 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?
On May 4, 2013 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking jo...@sicking.cc 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
* Jonas Sicking wrote:
On May 4, 2013 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote:
We also don't reuse keep-alive http connections.
Are we talking about persistent connections as per
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
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 w...@adambarth.com wrote:
How does withCredentials interact with TLS client certificates? Ideally
13 matches
Mail list logo
