Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Workflow:Puppeteer Puppeteer Request Interception

From Leeroopedia
Knowledge Sources
Domains Browser_Automation, Network_Control, Performance_Optimization
Last Updated 2026-02-11 23:30 GMT

Overview

End-to-end process for intercepting, inspecting, modifying, and blocking network requests in Puppeteer-controlled browsers.

Description

This workflow covers the standard procedure for controlling network requests made by a browser page using Puppeteer's request interception APIs. When interception is enabled, every outgoing request is paused and routed to an event handler where it can be inspected (URL, method, headers, resource type), then either continued (optionally with modified headers/URL/body), responded to with a custom response, or aborted entirely. This enables use cases like blocking unwanted resources (images, ads, tracking scripts), mocking API responses for testing, injecting custom headers, and monitoring network traffic.

Usage

Execute this workflow when you need to control or observe network requests during browser automation. Common scenarios include: blocking images or stylesheets to speed up page loads during scraping, mocking API endpoints for UI testing, injecting authentication headers, logging all network traffic, filtering third-party resource requests, and simulating network error conditions.

Execution Steps

Step 1: Launch Browser And Create Page

Start a browser instance and open a new page. Request interception is configured per page, so the page must be created before enabling interception.

Key considerations:

  • Interception is page-specific; each page manages its own interception state
  • Launch options like proxy settings interact with interception behavior

Step 2: Enable Request Interception

Activate request interception on the page by calling setRequestInterception(true). This instructs the browser to pause all outgoing network requests and emit them as events that the handler can process. Without enabling interception, request events are informational only.

Key considerations:

  • Must be called before navigation for the interception to apply to initial page load
  • Enabling interception adds latency since every request pauses for handler processing
  • Both CDP and BiDi backends support request interception

Step 3: Register Request Handler

Attach an event listener for the 'request' event on the page. Each intercepted request provides an HTTPRequest object with methods to inspect request details and take action. The handler must call exactly one of: continue(), respond(), or abort() for each intercepted request.

Key considerations:

  • Every intercepted request MUST be resolved (continue, respond, or abort)
  • Failing to resolve a request will cause the page to hang
  • Use request.resourceType() to filter by type (image, stylesheet, script, xhr, document, etc.)
  • Use request.url() to filter by URL pattern
  • Multiple handlers can be registered; cooperative interception uses priority-based resolution

Step 4: Navigate And Process Requests

Navigate the page to the target URL. As the page loads, each network request triggers the registered handler(s). The handler processes each request according to the defined rules.

Actions available per request:

  • continue() - Allow the request to proceed, optionally overriding URL, method, headers, or post data
  • respond() - Provide a custom response (status, headers, body) without making a network request
  • abort() - Block the request with an optional error reason (failed, aborted, timedout, accessdenied, etc.)

Step 5: Perform Page Operations

Continue with page interactions (screenshots, scraping, etc.) while interception remains active. All subsequent navigations and resource loads on this page will continue to be intercepted.

Key considerations:

  • Interception remains active until explicitly disabled or the page is closed
  • Call setRequestInterception(false) to disable if no longer needed
  • Be careful not to abort requests that subsequent operations depend on

Step 6: Close Browser

Terminate the browser to release all resources. Interception is automatically cleaned up when the page or browser is closed.

Execution Diagram

GitHub URL

Workflow Repository