On 08/25/2013 10:13 PM, Mark Hammond wrote:
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 :)
Thanks for looking into this Mark! I'm sure Patrick will have some
thoughts here, but he's on PTO this week, so be patient. Honza or Brian
may have ideas here too.
Jason
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
