There are 4 non-test consumers of
appendRedirectHistoryEntry in tree: https://searchfox.org/mozilla-central/search?q=appendredirecthistoryentry
93 newLoadInfo->AppendRedirectHistoryEntry(entry, isInternalRedirect); // found in nsBaseChannel::Redirect
1409 redirectLoadInfo->AppendRedirectHistoryEntry(entry, true); // found in mozilla::net::DocumentLoadListener::SerializeRedirectData
3952 newLoadInfo->AppendRedirectHistoryEntry(entry, isInternalRedirect); // found in mozilla::net::HttpBaseChannel::CloneLoadInfoForRedirect
1550 mLoadInfo->AppendRedirectHistoryEntry(entry, false); // found in mozilla::net::HttpChannelChild::CleanupRedirectingChannel
Looking at these consumers:
what's striking is that they all do the same thing to determine the URL to add: they ask the script security manager for the channel's URI principal (the http channels use the channel's own
GetURIPrincipal helper for this, which just defers to the script security manager anyway, and has no other callers).
The ones in http code also both check the computed referrer and remote address off the channel.
So ISTM we could just push the construction of the entry into
AppendRedirectHistoryEntry itself, and have it take an nsIChannel as an argument. As a bonus, this makes it easier to call this method from JS code, because it is likely to have a channel reference, but cannot itself construct the native redirect history entry objects, and any JS implementation is not going to be threadsafe.
I have a patch for this.