On Tue, Nov 20, 2018 at 3:48 PM Honza Bambas wrote:
> Our implementation reflects the reality we can see in the wild. I
> believe the spec has always been wrong here, and apparently has never
> been widely respected by servers because commas may be contained in the
> challenge header values. The
This should be decided once and for all. The complicated parsing of ", "
separated auth headers was exactly my argumentation against changing XHR's
behaviour. But it was discarded.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lis
On 2018-11-20 15:38, john.bieling--- via dev-platform wrote:
For me it would be interesting to understand, if you consider the header send
by contacts.icloud.com to by invalid, even though it fully complies with the
spec
Our implementation reflects the reality we can see in the wild. I
beli
I mean ", " separated of course.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I have a working impl. now and just looking at 401 is not sufficient.
The user could indeed have provided a wrong password. The only way to know, if
the 401 was caused because nsIHttpChannel did not even try to authenticate, is
by checking wether it has send a Authorization header back to the s
On 11/20/18 9:19 AM, Anne van Kesteren wrote:
Similar, e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=872772.
Doesn't seem like a high priority for anyone to fix.
Well... If:
1) All the browsers agree here (do they?)
2) There are concerns that there may be sites depending on the b
On Tue, Nov 20, 2018 at 3:15 PM Boris Zbarsky wrote:
> On 11/20/18 8:55 AM, Honza Bambas wrote:
> > because comma can be contained in a single header value
> > (against what the spec says). We can't correctly separate the headers
> > by commas, potentially even opening security holes if we do tha
On 11/20/18 8:55 AM, Honza Bambas wrote:
because comma can be contained in a single header value
(against what the spec says). We can't correctly separate the headers
by commas, potentially even opening security holes if we do that blindly.
Do we know what other UAs do here?
-Boris
_
On 2018-11-20 10:31, john.bieling--- via dev-platform wrote:
@Anne van Kesteren
Solved that by checking getRequestHeader("Authorization") in case of 401 and if
that is missing, I know nsIHttpChannel did not try to authenticate.
First, I can confirm that we expect multiple authentication chall
On Tue, Nov 20, 2018 at 9:50 AM john.bieling--- via dev-platform
wrote:
> Thanks for your feedback. As you have the much deeper knowledge about these
> thinks, I think it would be better if you file that bug?
I forgot that it was already filed and marked as a dependency:
https://bugzilla.mozilla
@Anne van Kesteren
Solved that by checking getRequestHeader("Authorization") in case of 401 and if
that is missing, I know nsIHttpChannel did not try to authenticate.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.or
@Anne van Kesteren
Thanks for your feedback. As you have the much deeper knowledge about these
thinks, I think it would be better if you file that bug? I think you can get
the report much more to the point than I could describe it?
Related Question: In my Add-On I made the transition from fetch
On Tue, Nov 20, 2018 at 9:20 AM john.bieling--- via dev-platform
wrote:
> Now it looks like that nsIHttpChannel itself is not able to split
> WWW-Authenticate headers?
Right, I reported that in
https://bugzilla.mozilla.org/show_bug.cgi?id=1491010#c22.
> Should I add a link to this thread to th
FYI: I observed this with Thunderbird 60.3.1 (the current stable release)
Is this related to
https://bugzilla.mozilla.org/show_bug.cgi?id=1491010
I reported this bug because fetch()'s response.headers.get("WWW-Authenticate")
returned "null" if TWO such headers are received (as you suggested).
On 11/19/18 5:07 PM, john.biel...@googlemail.com wrote:
WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic
realm="Newcastle"
I expect this would work if you sent it as:
WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle"
WWW-Authenticate: Basic realm="Newcastle"
Yes, per sp
Hi,
today I wanted to authenticate a PROPFIND against
https://contacts.icloud.com
which returns the following WWW-Authentication header:
WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic
realm="Newcastle"
Usually, on a fresh/new connection, nsIHttpChannel will first do an
unauthe
16 matches
Mail list logo
