Add support for headers, cookies, method and body arguments for "network.continueRequest" command
Categories
(Remote Protocol :: WebDriver BiDi, task, P2)
Tracking
(firefox128 fixed)
Tracking | Status | |
---|---|---|
firefox128 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Blocks 2 open bugs, )
Details
(Whiteboard: [webdriver:m11:blocked], [wptsync upstream][webdriver:relnote])
Attachments
(5 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1850680 - [bidi] Add support for headers, cookies, method and body parameters in continueRequest
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
This bug will take care of implementing the network.continueRequest command.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 1•1 year ago
|
||
When implementing this command we should also update the interception code in the supported phases to create a promise when a request is intercepted so that we can cleanup the blockedRequests map once the request is resumed and completed.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 2•11 months ago
|
||
With bug 1874206 the plan is to cover the required arguments only for now.
Assignee | ||
Comment 3•9 months ago
|
||
Hi Valentin,
I know we haven't landed the new observer notification yet (Bug 1849686), but I wanted to check with you if the current requirements for modifying requests with WebDriver BiDi sound feasible. Maybe some of them will actually be more challenging if we intercept the request "late".
The spec bit is covered in https://w3c.github.io/webdriver-bidi/#command-network-continueRequest
For this command, we expect the request to be blocked in the beforeRequestSent
phase, which should be done when we receive the notification from Bug 1849686. We want to allow users to modify the following properties of the request:
- body
- headers
- cookies (in that case it's probably just a subset of headers)
- method
- url
Do you think it should be feasible, maybe you have concerns for some of those properties?
I can see some APIs on nsIHttpChannel eg to set headers, but maybe there are other which can be useful here?
Comment 4•9 months ago
|
||
Changing the URL at that point is probably not very straightforward. HttpBaseChannel::mURI is set in ::Init and stays the same for the entire lifetime of the channel. By the time we send out beforeRequestSent we've already done all the security checks, set the path in the requestHead, etc.
Changing the URL at this point would require us to make additional changes to the channel (not impossible, but right now it wouldn't work - maybe instead of changing the URL we can do an internal redirect instead).
The method can probably be changed at this point - we have HttpBaseChannel::SetRequestMethod - but some checks are performed before this - so the request might not be valid. And I seem to remember we had some assertions that get/head requests must not have a body - but can't find them right now.
Changing the body and headers (including cookies) is probably fine. You can use SetUploadStream to change the body - note that it also sets the methdod.
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 5•8 months ago
|
||
I have been testing this using another observer notifications: http-on-before-connect
, which in theory should be raised earlier than the one we are trying to add.
I could successfully update request headers / cookies thanks to setRequestHeader.
However for both the method
and the body
, the APIs I used all threw NS_ERROR_IN_PROGRESS
. Setting the method for instance uses the ENSURE_CALLED_BEFORE_CONNECT
macro.
Valentin, do you think about this? Is it too late to try to update the method/body of the channel?
Comment 6•8 months ago
|
||
I think that check exists because some security headers/flags/decisions are made after onModifyRequest, and changing them wouldn't be great, especially for your random webextension.
However, in this case I'm thinking we might be able to temporarily relax this constraint?
We can StoreRequestObserversCalled(false);
before calling the observer notification, and set it back to true afterwards.
Assignee | ||
Comment 7•7 months ago
|
||
Depends on D209524
Updated•7 months ago
|
Assignee | ||
Comment 8•7 months ago
|
||
Depends on D209538
Assignee | ||
Comment 9•7 months ago
|
||
Depends on D209539
Assignee | ||
Comment 10•7 months ago
|
||
Depends on D209540
Assignee | ||
Comment 11•7 months ago
|
||
Depends on D209541
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Assignee | ||
Updated•6 months ago
|
Comment 14•6 months ago
|
||
Comment 16•6 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/aeeda14ca643
https://hg.mozilla.org/mozilla-central/rev/1c4084febc9c
https://hg.mozilla.org/mozilla-central/rev/8ff3dc16fcf9
https://hg.mozilla.org/mozilla-central/rev/9a98ace82049
https://hg.mozilla.org/mozilla-central/rev/3147811b0446
Comment 18•6 months ago
|
||
Backed out for causing high frequency failures at url_patterns.py
Backout link: https://hg.mozilla.org/integration/autoland/rev/c5f0d71de69cf598d009f69c9ddf56fb6058bc9e
Failure log: https://treeherder.mozilla.org/logviewer?job_id=459502969&repo=autoland&lineNumber=128070
Comment 19•6 months ago
|
||
Comment 21•6 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2bbe2132d874
https://hg.mozilla.org/mozilla-central/rev/bcccf3ed3aea
https://hg.mozilla.org/mozilla-central/rev/a09656081892
https://hg.mozilla.org/mozilla-central/rev/7fe452e20b6d
https://hg.mozilla.org/mozilla-central/rev/aa0a319bd0bc
Comment 23•6 months ago
|
||
FYI https://github.com/puppeteer/puppeteer/pull/12483 is the upstream PR to get more tests enabled.
Updated•5 months ago
|
Description
•