Requesting blocking to get wanted+. This won't be hard to at least add some of the common ones to the static cache, and maybe a follow-up for the dynamic one?
...and shaver suggested just having nsIIOService.httpProtocol, .httpsProtocol, etc. Would help for the cases where we know what we want.
(In reply to comment #2) > ...and shaver suggested just having nsIIOService.httpProtocol, .httpsProtocol, > etc. Would help for the cases where we know what we want. While we don't have many jar files nowadays, it might be a good idea to have a property for the jar protocol too?
jar is not in necko. don't add a jar entry here.
Yeah, I'd take a patch, if everyone here is done their blockers.
I did the trivial patch earlier, but the tricky part is that the cache will only hold things that support nsIWeakReference, which some of those other protocol handlers don't. Is fixing that as simple as just adding the relevant interface to the NS_IMPL_ISUPPORTS#() list?
https://developer.mozilla.org/en/nsSupportsWeakReference But I'd rather you didn't add cache entries for protocol handlers that aren't implemented in necko (like the moz-anno one or some others mentioned in comment 0)
How do you propose applications handle other frequent protocols?
Do you get consecutive misses for the same protocol or are they random?
checking on this today, the list has been updated somewhere along the way to include data and https too.
(In reply to Patrick McManus [:mcmanus] from comment #10) > checking on this today, the list has been updated somewhere along the way to > include data and https too. https://bugzilla.mozilla.org/show_bug.cgi?id=1149228
spot checking my cache misses the only obvious thing to add, at least as handled by necko, is about (and safe about)
Created attachment 8699520 [details] [diff] [review] cache about protocol handlers
https://hg.mozilla.org/integration/mozilla-inbound/rev/a2a07b55949a1e24069ca4695af932ea710067f8 Bug 524232 - cache about: protocol handlers r=mayhemer