Add API similar to redirectTo using internal redirect
Categories
(Core :: Networking, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox132 | --- | fixed |
People
(Reporter: jdescottes, Assigned: sekim)
References
Details
(Whiteboard: [necko-triaged][necko-priority-queue])
Attachments
(2 files, 1 obsolete file)
For Bug 1898158, webdriver BiDi would need an API to redirect using internal redirects so that the content page is not aware of the redirect. More over we need the redirect to be handled after http-on-before-connect, because that's where WebDriver BiDi will attempt to update the URL.
(In reply to Kershaw Chang [:kershaw] from Bug 1898158 comment #6)
(In reply to Julian Descottes [:jdescottes] from Bug 1898158 comment #5)
Let me start by asking again here, because while working on provideResponse I spotted some APIs which could be helpful.
Kershaw: For WebDriver BiDi network interception, we need to be able to change the url of a request blocked in the "beforeRequestSent" phase, which corresponds to http-on-before-connect at the moment.
We might be able to handle this as an internal redirect, as long as the page cannot detect the redirection. Eg if we navigate to a.com and update the url to b.com via network interception, the window.location.href should still be a.com.
Do you think an internal redirect would work here? It might lead to create duplicated events, but that's something we might be able to handle on our side. Or would we need to add a new API on necko side to support this scenario?
Yes, I think internal redirect should work here. However, our current RedirectTo API doesn't support internal redirect. I assume we my need to add another function argument for this.
Moreover, we need some changes around here, because the channel doesn't handle redirect immediately afterhttp-on-before-connect.
| Reporter | ||
Comment 1•1 year ago
|
||
Moreover, we need some changes around here, because the channel doesn't handle redirect immediately after http-on-before-connect.
Do you mean the redirect is usually handled later or is it handled before?
In theory if it's handled "later" it could be fine for us, we don't need it to happen immediately in http-on-before-connect. Or maybe redirects are only handled when we start processing the response so that would be an issue here?
Comment 2•1 year ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #1)
Moreover, we need some changes around here, because the channel doesn't handle redirect immediately after http-on-before-connect.
Do you mean the redirect is usually handled later or is it handled before?
In theory if it's handled "later" it could be fine for us, we don't need it to happen immediately in http-on-before-connect. Or maybe redirects are only handled when we start processing the response so that would be an issue here?
I mean the redirect is handled too late. If you call redirectTo in http-on-before-connect, the channel handles the redirect at here, which is too late.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
•
|
||
By looking at the relevant code, the following points should be addressed if I understood everything correctly:
redirectToshould have an extra argument for internal redirect.redirectToshould be moved such that it is called right afterhttp-on-before-connect:
https://searchfox.org/mozilla-central/rev/56dd89bcf4d3b85f66621e89eac6e2936ad382d9/netwerk/protocol/http/nsHttpChannel.cpp#879
Are there any additional considerations to keep in mind?
Comment 5•1 year ago
|
||
(In reply to Sean Kim from comment #4)
By looking at the relevant code, the following points should be addressed if I understood everything correctly:
redirectToshould have an extra argument for internal redirect.
This is correct.
redirectToshould be moved such that it is called right afterhttp-on-before-connect:
https://searchfox.org/mozilla-central/rev/56dd89bcf4d3b85f66621e89eac6e2936ad382d9/netwerk/protocol/http/nsHttpChannel.cpp#879
What we need is handling the redirect after http-on-before-connect, not moving redirectTo.
Maybe adding the code below is enough, but there could be more details need to be figured out.
if (mAPIRedirectToURI) {
return AsyncCall(&nsHttpChannel::HandleAsyncAPIRedirect);
}
| Assignee | ||
Comment 6•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 7•1 year ago
|
||
| Assignee | ||
Comment 8•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 10•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/303792420667
https://hg.mozilla.org/mozilla-central/rev/361b0802c006
Description
•