I run into multiple issues with nsCookieService. 1. It is not able to store different cookie sets for connections for different users to the same host, only one set per host survives (the last one). This behavior can be triggered by creating nsIChannel from a nsIUri containing a username (https://username@host/path/to/something). nsIChannel is using the prePath (including the username) to handle the connections and it is thus possible to have multiple channels to the same host. But when opening the connection via asyncOpen, at some point AddCookiesToRequest() and there nsCookieService::GetCookieStringFromHttp() is called, which only looks at the host of the passed nsIUri. If only one connection to server XY is opened, this is no issue. As soon as two or more such "user-connections" are opened to the same server, this causes problems. This is one of the reasons for the long standing lightning bug, not being able to subscribe to multiple calendars on the same server for different users, if the server sends session cookies. By setting network.cookie.cookieBehavior = 1, multiple connections are indeed possible, because cookies are rejected. So this sort of confirms my findings, but rejecting cookies globally is actually not an option.  I think this is a bug in nsCookieService. Do you agree? Is it worth working on this and will you accept a patch here? 2. It would be nice to ignore cookies per connection by adding flags to mimic network.cookie.cookieBehavior. How about adding more SEC_COOKIES_* flags to https://dxr.mozilla.org/mozilla-beta/source/netwerk/base/nsILoadInfo.idl which allow to reject cookies and which is passed onto to nsCookieService? In generall: What is the future of the entire nsIchannel stuff? Are there plans to replace it by the fetch API so working on this is not suggested at all? Thanks for your feedback, John

Hi John, the cookie service, as well as nsIChannel and the remaining network infrastructure is part of mozilla-central, and therefore out of our reach. The best place to discuss this would either be in a bug in Core :: Networking, or on a list such as mozilla.dev.platform. The Firefox and Platform developers will be able to respond there. I think it would be valuable to see what the spec says in this regard, i.e. if the origin that is relevant for the cookie domain should include the username. If the answer to that is no, I fear their verdict will be WONTFIX. Instead of hacking around by setting a username, I would enjoy if it were possible to do your own auth and cookie management. This way we could write our own management code for e.g. calendar that would work per-calendar, and allow using separate cookie stores. If the cookies are added automatically right now with no way to stop that from happening, I can imagine m-c would accept a patch to control that. Maybe they would also accept a patch to be able to pass a "cookie session", that could be serialized separately after the connections have been made. As for the future of nsIChannel, fetch is actually most likely built on top of nsIChannel. I don't foresee this going away any time soon. Still, I would like to see Thunderbird/Lightning code use fetch where possible because it is easier to read and nicer to work with. The only issue is that fetch was made for website connections and may be lacking some of the features necessary for application access that nsIChannel currently provides. If you file an m-c bug, please do cc me :) Philipp > On 10. Sep 2018, at 5:06 AM, John Bieling <john.bieling@gmx.de> wrote: > > I run into multiple issues with nsCookieService. > > > 1. It is not able to store different cookie sets for connections for different users to the same host, only one set per host survives (the last one). > > This behavior can be triggered by creating nsIChannel from a nsIUri containing a username (https://username@host/path/to/something). nsIChannel is using the prePath (including the username) to handle the connections and it is thus possible to have multiple channels to the same host. > > But when opening the connection via asyncOpen, at some point AddCookiesToRequest() and there nsCookieService::GetCookieStringFromHttp() is called, which only looks at the host of the passed nsIUri. If only one connection to server XY is opened, this is no issue. As soon as two or more such "user-connections" are opened to the same server, this causes problems. This is one of the reasons for the long standing lightning bug, not being able to subscribe to multiple calendars on the same server for different users, if the server sends session cookies. > > By setting network.cookie.cookieBehavior = 1, multiple connections are indeed possible, because cookies are rejected. So this sort of confirms my findings, but rejecting cookies globally is actually not an option. I think this is a bug in nsCookieService. > > Do you agree? Is it worth working on this and will you accept a patch here? > > > > 2. It would be nice to ignore cookies per connection by adding flags to mimic network.cookie.cookieBehavior. How about adding more SEC_COOKIES_* flags to > https://dxr.mozilla.org/mozilla-beta/source/netwerk/base/nsILoadInfo.idl > which allow to reject cookies and which is passed onto to nsCookieService? > > > In generall: What is the future of the entire nsIchannel stuff? Are there plans to replace it by the fetch API so working on this is not suggested at all? > > > Thanks for your feedback, > John > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net