webRequest.onBeforeRequest returns incorrect url for redirects
Categories
(WebExtensions :: Request Handling, defect, P2)
Tracking
(Not tracked)
People
(Reporter: alexander.belykh, Unassigned)
References
Details
(Whiteboard: [webRequest])
Comment 1•8 years ago
|
||
Comment 2•7 years ago
|
||
Updated•7 years ago
|
Comment 3•7 years ago
|
||
Updated•7 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
I'm bumping the priority of this bug, because the underlying primitive is used in many places, with the underlying assumption that the url reflects the requested URL. Using a different URL can result in bad (security-sensitive) decisions.
I ran into this issue while writing a unit test that confirms that a ChannelWrapper's URL (instantiated at http-on-modify-request) is showing the redirect URL. It looks like the redirect-awareness of ChannelWrapper is handled via the channel.channel assignment in onChannelReplaced, which is called by an asyncOnChannelRedirect handler, which in turn is only registered when any webRequest.onBeforeRedirect listener is present in Firefox. Presently, there is a built-in extension with such a listener, but we should not be relying on that as it is very brittle.
And for the record, I also note the use of newChannel.originalURI in onChannelReplaced (called by asyncOnChannelRedirect), but the IDL file claims that originalURI is unusable at that time. The comment was added in bug 1732250. If this bug gets fixed without unit tests looking at this originalURI usage etc, then we should have a new bug filed.
Updated•3 years ago
|
Comment 5•3 years ago
|
||
The webRequest.onBeforeRequest bug has been fixed by bug 1448599, specifically the change at https://hg.mozilla.org/mozilla-central/rev/5c9c6f5a4ca3#l2.30
The underlying issue still exists for the ChannelWrapper primitive, so I will file a new bug for that.
Description
•