On Fri, Oct 12, 2018 at 2:30 PM Ryan VanderMeulen wrote:
> As was noted in the bug, deciding to explicitly un-support MSVC is a
> decision which merits wider discussion and is not something I wanted to
> tackle in that bug.
>
>
Has such a discussion been planned or already happened? If not, can
@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
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 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
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:
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
@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
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
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
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
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
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.
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
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
15 matches
Mail list logo
