Implement support for Fetch.enable, Fetch.disable, Fetch.requestPaused, and basics for Fetch.continueRequest
Categories
(Remote Protocol :: CDP, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [puppeteer-beta2-mvp])
This bug will cover the initial work to get the basic features of the Fetch domain implemented. In this case the following two commands are required:
https://chromedevtools.github.io/devtools-protocol/tot/Fetch#method-enable
https://chromedevtools.github.io/devtools-protocol/tot/Fetch#method-disable
Once enabled every network request has to be paused by emitting a Fetch.requestPaused
event.
To continue the request the client has to call one of failRequest, fulfillRequest or continueRequest/continueWithAuth, but that is out of scope for this particular bug.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
Also see bug 1587426 comment 1 for a possible implementation idea.
Comment 2•5 years ago
|
||
It sounds like the plan is to make it possible to intercept network requests but not to actually respond to them? That doesn't seem like an obviously useful subset of functionality. I would expect to work with any testsuite we would need at least some of the methods for resuming or explicitly failing the request. Unfortuantely I think this domain is nearly atomic in terms of usefulness; it's hard to pick a subset such that implementing that subset makes sense without also implementing the rest. Maybe continueWithAuth
and the methods for getting the response body are outside that subset. fulfillRequest
could also be outside a very minimal subset, but I think that's the main use case for this feature, so it would at least need to be a prompt followup.
Comment 3•5 years ago
|
||
Also I think the intended link may have been bug 1587426 comment 1
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to James Graham [:jgraham] from comment #3)
Also I think the intended link may have been bug 1587426 comment 1
Indeed. Somehow I delete the 6 when splitting the URL.
Otherwise you seem to be right. We should also have at least continueRequest
, and let Firefox continue with the original request. Additional parameters for it could be added via bug 1587426. Thanks!
Reporter | ||
Comment 5•5 years ago
|
||
Jumped up a bit too early here. I just got the Puppeteer examples working, and see some other stuff I would like to get fixed first. Will start on this bug soon.
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
Note that these missing APIs currently block the Selenium BiDi work to get Firefox supported. One use case here is to bypass basic authentication sites.
Comment 7•4 years ago
|
||
Hi there - wanted to get an update on support for this function. Will we be getting network intercept capability in an upcoming Nightly build?
Reporter | ||
Comment 8•4 years ago
|
||
Thanks for asking. So given that the team is working on other more important stuff right now, we won't be able to get support added soon. But when we get started with the implementation of WebDriver BiDi early next year we will definitely have to get that support added. So please stay tuned for a while. Thanks.
Reporter | ||
Comment 9•4 years ago
|
||
When someone starts to implement these APIs please also have a look at bug 1587426 comment 3.
Assignee | ||
Updated•4 years ago
|
Updated•2 years ago
|
Reporter | ||
Comment 10•1 year ago
|
||
We are not going to implement network interception for CDP. Instead we have it now on our focus for the WebDriver BiDi milestone 8 and 9.
Description
•