Subject: Speeding up jar protocol Date: Thu, 27 Jul 2000 23:42:12 -0700 From: Warren Harris <warren@netscape.com> To: Mitchell Stoltz <mstoltz@netscape.com> Mitch, I think that the jar protocol is slow because in the Open method we get the certificate principal from the jar entry (code after the comment //-- Verify signature, if one is present, and set owner accordingly). Is there some way we can defer computing this? If the jar channel is wrapped in a chrome url, we're just going to grab the system principal later anyway. Warren

If we turn on jar packaging without fixing this problem, people will shoot us for making the startup time so slow. Marking nsbeta3.

Mitch: Can you verify this patch?

There's a problem with this patch. Computing the principal requires mJAR (note mJAR->GetCertificatePrincipal) but when GetOwner() is called there's no guarantee that mJAR is still around; it gets released in the Close() function which may or may not happen before GetOwner() is called. We might have to keep mJAR around longer. Otherwise this patch will cause some segfaults.

Can you just reopen the jar again? It will probably be in the cache anyway. Otherwise, you could hang on to mJAR until the channel is destroyed.

Which do you suggest?

Let's try reopening it if it's needed.

checking in warren's fix for this. If there are problem, let me know and reopen.

We still need to free mJAR from the nsZipReaderCache somewhere; just commenting out the code in Close() is not enough. As it stands, mJAR will never be freed. I have a major rewrite of nsJARChannel ready to go in, just waiting on Warren's review, and it includes this fix, so I will reclose this bug when the full changes go in.

No, we changed the zip cache so that when the channel drops its reference, the entry gets removed from the cache automatically. In this case, it's when the channel goes away. Closing this -- the other bug will deal with your jar channel rewrite.

Verified per warren's comments.