Feature request: possibility to handle `page.on('request',...)` in several places
See original GitHub issueUse case:
I am developing a testkit which does page.on('request', ...)
in order to intercept specific requests.
The problem: A user can write another interceptor which handles specific requests and calls request.continue()
for all the rest (as this is mandatory for requests that we do not handle).
As a result, only the first request handler “wins” (the second handler will receive “request is already handled!” error.)
A possible solution:
Today we must have request.continue()
for every request that we do not want to handle. What if puppeteer will do it by default, for requests that it finds as “unhandled”. In this case, each handler will only take care of its own interceptors, and will do nothing about the rest of requests.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:18
- Comments:6 (2 by maintainers)
Top Results From Across the Web
How To Handle Feature Requests - The Ultimate Guide for ...
How to track and manage feature requests in an organized and systematic way, all leading to better product execution.
Read more >How To Manage Feature Requests [Template included]
This guide will teach you everything about feature requests – how to process them, manage them, respond to them, prioritize them – so...
Read more >How to Manage Product Feature Requests – 6 Best Practices
A feature request is an idea a customer sends your way to make you understand how he's using your product, and what he...
Read more >Feature Request Template: How to Manage Suggestions at ...
Every feature request needs a name. It's usually a few words long, sometimes a full sentence. This name will help you (and other...
Read more >10 Tips to Improve Your Feature Request Responses - Nicereply
You might even begin to uncover that what you thought they were asking about is possible with a different part of your product....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Puppeteer could implement a public API to check whether a request is already handled or not. There is already the
_interceptionHandled
property on theRequest
class, we would essentially just need a getter for that. Any thoughts? @aslushnikov@yanivefraim With the currently-exposed API, it’s unclear when the request is “unhandled”. Consider an artificial example of “network throttling” using request interception:
Since Puppeteer gives away control over the request to the client, client might continue them anytime in future as they require. They might even drop the request on the floor without continuing to simulate server stalling. So from Puppeteer’s stand point, we can’t auto-continue requests since it will break many valid usecases.
However, it looks like your testkit introduces certain conventions over request interception, e.g. “request should be either synchronously aborted, or it will be auto-continued” (i might got it wrong). In this case, you can auto-continue all requests in a subsequent microtask:
Let me know if I understand you correctly and if it helps.