This is a followup to the thread "Forcing every request from a docShell
to use LOAD_ANONYMOUS". In that thread, I mentioned on some issues I'm
having with speculative connections and SSL authentication, but I no
longer believe they are issues relating to LOAD_ANONYMOUS.
In short, I now believe speculative connections alone can cause SSL
authentication prompts, even (or particularly) when those speculative
connections *are not* used.
In one example that I can reproduce, we make a speculative connection to
a site (and never attempt a real connection, so it never gets used.)
Later, a timer fires to prune dead connections.
nsHttpConnectionMgr::OnMsgPruneDeadConnections is called, which
(indirectly) calls nsHttpConnection::IsAlive(), which tries to read 1
byte from the stream with the PR_MSG_PEEK flag. We then end up in
ssl_SecureRecv() which notices we haven't done the SSL handshake, so
prompts for a certificate for authentication.
IOW, simply checking if a socket is still alive may prompt for auth.
Secondly, I *think* there's another example of this. A speculative
connection ends up calling
nsHttpConnectionMgr::nsHalfOpenSocket::OnOutputStreamReady() - and
occasionally we enter the block at
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpConnectionMgr.cpp#2911
The comments from this block say:
// if we are using ssl and no other transactions are waiting right now,
// then form a null transaction to drive the SSL handshake to
// completion. Afterwards the connection will be 100% ready for the next
// transaction to use it.
which is doing exactly what it describes - completing the SSL
transaction, which prompts for auth - even though this was a speculative
connection.
Does this sound correct? If so, what can we do about it? (I'll refrain
from speculating until people who actually know what they are talking
about chime in :)
Any thoughts or insights?
Thanks,
Mark
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
