Re: Cookies are no longer stored by nsIHttpChannel?

Hi Andrea, I can confirm, that network.cookieSettings.unblocked_for_testing is indeed fixing this for me. But since this pref looks like it will not stay long, I would like to fix this with the worker approach. You said you would like to move this discussione to IRC, where can I find you?

Re: Cookies are no longer stored by nsIHttpChannel?

Hi Andrea, I was already going thru that CookieSettings docuemnt, but are you sure that is alreadfy in the ESR68 branch? I tried to access loadInfo.cookieSettings and got back an error. Where can I find you on IRC? Which channel/nick? ___

Re: Cookies are no longer stored by nsIHttpChannel?

More details: The same code works in TB60 and in the cookie list of the general options I can see all sorts of cookies being stored. In TB68, none of the expected cookies show up in the cookie list. Did something change in that region? What do I need to do to allow a channel / principal to

Cookies are no longer stored by nsIHttpChannel?

Hi, I have run into something strange. This is how I create network connections in my (Thunderbird-) AddOn: let channel = Services.io.newChannelFromURI( aConnection.uri, null, Services.scriptSecurityManager.createCodebasePrincipal(aConnection.uri, { userContextId }), null,

Re: Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel

Perfect! Having seen that, I also found the "contentType" attribute and its description here: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIChannel which allows me to mimic the behaviour. Thanks a lot for the pointer! John

Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel

I am working on a wrapper for nsIHttpChannel with the interface of MLHttpRequest. Mainly to be able to use the codeBbasePrincipal (or ContextPrincipal as it is called now I think) with XHR requests, but without authors having to rewrite their code. This is for Thunderbird Add-Ons, which still

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

Alternatively, the admin wants me to send a bogus authenticate header, like Authenticate: X to trigger the authentication. I really do not like that. Maybe I can get him to jump into the discussion. ___ dev-platform mailing list

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

No, the server is not controlled by me. The admin expects clients to send a Basic Auth header without having seen the WWW-Authenticate header, if I do not want to access the resource unauthenticated. For me this looked wrong from the beginning, but just wanted to make sure I am not missing

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

Thanks for your reply. I do not want to manually add a `Authentication` request header, as I also do not know what methods are allowed without having seen the WWW-Authentication header (and just trying basic auth is not an option for me). I was hoping there was some established mechanism to

Authentication strategy for servers, which do not return a 401 on unauthenticated requests

nsIHttpChannel is usually doing an unauthenticated request to a remote URL to get the WWW-Authentication header from the 401 response and then pick one of the allowed methods to authenticate. I am running into an issue, where the server is not returning a 401 but actually returns a result for

Inquiry: What about making fetch() auto-contained by username?

That title is a bit bulky, but it is hard to find a one line summary for this thread :-) After having understood how originAttributes and containers work with nsIHttpChannel, I was finally able to fix all sorts of connection problems. I am now able to isolate connections to the same host but

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

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

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

I mean ", " separated of course. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

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

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

@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

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

@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

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

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).

nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

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

mozilla-esr60 fails to build on windows

I was able to build mozilla-central on my Windows 10, but Mozilla-esr60 fails: John@R2D2 ~/Documents/Mozilla/source60 $ ./mach build 0:02.31 Clobber not needed. 0:02.32 Adding make options from None MOZ_OBJDIR=c:/Users/John/Documents/Mozilla/source60/obj-i686-pc-mingw32

Re: What is the future of XMLHttpRequest.mozAnon ?

So to summarize this topic and all the things that are currently going on: - mozAnon is not to stay forever, because XHR is superseded by fetch() wich has an option for that as well - XHR.getResponseHeader() is going to be adjusted to match fetch() [= returning a comma-joined list] so using XHR

Re: What is the future of XMLHttpRequest.mozAnon ?

N! You may fix fetch() to support multiple auth headers again, but do not change how XHR returns them :-) What have I done ... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: What is the future of XMLHttpRequest.mozAnon ?

I do not think they will change that. RFC 7230 defines that behavior and the digest auth header is actually not a valid header in that respect. The mozilla impl. actually had a "getAll" method, which returned an array instead of a list. But that was non-standard and got removed. But we are

Re: What is the future of XMLHttpRequest.mozAnon ?

> Isn't this the same as supplying the crossOrigin:anonymous option to > fetch()? That is true, that is why I wrote "in other features". For example, if multiple www-authenticate headers are send, fetch will return them as a list joined by "," while XHR returns them as a list joined by "\n".

Re: What is the future of XMLHttpRequest.mozAnon ?

CromeOnly means, I can continue to use from (Thunderbird) AddOns, but not from a website? That would be ok. But removing it altogether would be a loss, because (with that mozAnon option) XHR has advantages in other features over fetch(). If I could vote, I would like to +1 for keeping it :-)

What is the future of XMLHttpRequest.mozAnon ?

Is mozAnon going to stay or are you thinking about removing that in the future? https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/mozAnon Thanks for your time, John ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: [Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header

I created a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1491010 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

[Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header

I encountered something strange. I am on TB60 trying to use the Fetch API. I create a GET or POST request without authentication and get back a 401 from the server and use response.headers.get("WWW-Authenticate") to eval the allowed authentication methods. This works fine, if the server