That title is a bit bulky, but it is hard to find a one line summary for th=
is thread :-)
After having understood how originAttributes and containers work with nsIHt=
tpChannel, I was finally able to fix all sorts of connection problems. I am=
now able to isolate connections to the same host but with different userna=
mes and provide them with isolated cookie caches and credential caches.=20
At the moment however it looks like, as this great functionality is only av=
ailable using nsIHttpChannel and thus is only avail for privileged code, bu=
t not to places, where only fetch() aor XHR is usable.
As fetch() seems to be the future, I will only talk about fetch() in this t=
hread, but one could think about the same for XHR. It is a general question=
of how to handle multiple connection to the same host for different users.
1) I do NOT want to propose to change the fetch() interface or its spec, ju=
st its internal handling. This proposal is not violating the fetch() spec (=
2) I want to propose, that fetch() will use containers per default in a way=
, that connections to the same host but with different usernames never shar=
e the same container. The base for this proposal is, that I cannot think of=
any use case, where it is actually desired to share (for example) the cook=
ie cache for such connections. It will always lead to authorization stealin=
g and things like that.
3) I do not want to expose the container management but let fetch() take ca=
re of selecting the correct userContextId.
What do you think about this?
Thanks for your time,