A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developer.chrome.com/docs/extensions/reference/webRequest below:

chrome.webRequest | API | Chrome for Developers

Skip to main content chrome.webRequest

Stay organized with collections Save and categorize content based on your preferences.

Note: As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API is unchanged and available for normal use. Policy installed extensions can continue to use "webRequestBlocking". Description

Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.

Permissions

webRequest

You must declare the "webRequest" permission in the extension manifest to use the web request API, along with the necessary host permissions. To intercept a sub-resource request, the extension must have access to both the requested URL and its initiator. For example:

{
  "name": "My extension",
  ...
  "permissions": [
    "webRequest"
  ],
  "host_permissions": [
    "*://*.google.com/*"
  ],
  ...
}

webRequestBlocking

Required to register blocking event handlers. As of Manifest V3, this is only available to policy installed extensions.

webRequestAuthProvider

Required to use the onAuthRequired method. See Handling authentication.

Concepts and usage Life cycle of requests

The web request API defines a set of events that follow the life cycle of a web request. You can use these events to observe and analyze traffic. Certain synchronous events will allow you to intercept, block, or modify a request.

The event life cycle for successful requests is illustrated here, followed by event definitions:

onBeforeRequest (optionally synchronous)
Fires when a request is about to occur. This event is sent before any TCP connection is made and can be used to cancel or redirect requests.
onBeforeSendHeaders (optionally synchronous)
Fires when a request is about to occur and the initial headers have been prepared. The event is intended to allow extensions to add, modify, and delete request headers (*). The onBeforeSendHeaders event is passed to all subscribers, so different subscribers may attempt to modify the request; see the Implementation details section for how this is handled. This event can be used to cancel the request.
onSendHeaders
Fires after all extensions have had a chance to modify the request headers, and presents the final (*) version. The event is triggered before the headers are sent to the network. This event is informational and handled asynchronously. It does not allow modifying or cancelling the request.
onHeadersReceived (optionally synchronous)
Fires each time that an HTTP(S) response header is received. Due to redirects and authentication requests this can happen multiple times per request. This event is intended to allow extensions to add, modify, and delete response headers, such as incoming Content-Type headers. The caching directives are processed before this event is triggered, so modifying headers such as Cache-Control has no influence on the browser's cache. It also allows you to cancel or redirect the request.
onAuthRequired (optionally synchronous)
Fires when a request requires authentication of the user. This event can be handled synchronously to provide authentication credentials. Note that extensions may provide invalid credentials. Take care not to enter an infinite loop by repeatedly providing invalid credentials. This can also be used to cancel the request.
onBeforeRedirect
Fires when a redirect is about to be executed. A redirection can be triggered by an HTTP response code or by an extension. This event is informational and handled asynchronously. It does not allow you to modify or cancel the request.
onResponseStarted
Fires when the first byte of the response body is received. For HTTP requests, this means that the status line and response headers are available. This event is informational and handled asynchronously. It does not allow modifying or canceling the request.
onCompleted
Fires when a request has been processed successfully.
onErrorOccurred
Fires when a request could not be processed successfully.

The web request API guarantees that for each request, either onCompleted or onErrorOccurred is fired as the final event with one exception: If a request is redirected to a data:// URL, onBeforeRedirect is the last reported event.

* Note that the web request API presents an abstraction of the network stack to the extension. Internally, one URL request can be split into several HTTP requests (for example, to fetch individual byte ranges from a large file) or can be handled by the network stack without communicating with the network. For this reason, the API does not provide the final HTTP headers that are sent to the network. For example, all headers that are related to caching are invisible to the extension.

The following headers are currently not provided to the onBeforeSendHeaders event. This list is not guaranteed to be complete or stable.

Starting from Chrome 79, request header modifications affect Cross-Origin Resource Sharing (CORS) checks. If modified headers for cross-origin requests do not meet the criteria, it will result in sending a CORS preflight to ask the server if such headers can be accepted. If you really need to modify headers in a way to violate the CORS protocol, you need to specify 'extraHeaders' in opt_extraInfoSpec. On the other hand, response header modifications do not work to deceive CORS checks. If you need to deceive the CORS protocol, you also need to specify 'extraHeaders' for the response modifications.

Starting from Chrome 79, the webRequest API does not intercept CORS preflight requests and responses by default. A CORS preflight for a request URL is visible to an extension if there is a listener with 'extraHeaders' specified in opt_extraInfoSpec for the request URL. onBeforeRequest can also take 'extraHeaders' from Chrome 79.

Starting from Chrome 79, the following request header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Note: Modifying the Origin request header might not work as intended and may result in unexpected errors in the response's CORS checks. This is because while extensions can only modify the Origin request header, they can't change the request origin or initiator, which is a concept defined in the Fetch spec to represent who initiates the request. In such a scenario, the server may allow the CORS access for the modified request and put the header's Origin into the Access-Control-Allow-Origin header in the response. But it won't match the immutable request origin and will result in a CORS failure.

Starting from Chrome 72, if you need to modify responses before Cross Origin Read Blocking (CORB) can block the response, you need to specify 'extraHeaders' in opt_extraInfoSpec.

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

Starting from Chrome 89, the X-Frame-Options response header cannot be effectively modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

Note: Specifying 'extraHeaders' in opt_extraInfoSpec may have a negative impact on performance, hence it should only be used when really necessary.

The webRequest API only exposes requests that the extension has permission to see, given its host permissions. Moreover, only the following schemes are accessible: http://, https://, ftp://, file://, ws:// (since Chrome 58), wss:// (since Chrome 58), urn: (since Chrome 91), or chrome-extension://. In addition, even certain requests with URLs using one of the above schemes are hidden. These include chrome-extension://other_extension_id where other_extension_id is not the ID of the extension to handle the request, https://www.google.com/chrome, and other sensitive requests core to browser functionality. Also synchronous XMLHttpRequests from your extension are hidden from blocking event handlers in order to prevent deadlocks. Note that for some of the supported schemes the set of available events might be limited due to the nature of the corresponding protocol. For example, for the file: scheme, only onBeforeRequest, onResponseStarted, onCompleted, and onErrorOccurred may be dispatched.

Starting from Chrome 58, the webRequest API supports intercepting the WebSocket handshake request. Since the handshake is done by means of an HTTP upgrade request, its flow fits into HTTP-oriented webRequest model. Note that the API does not intercept:

Redirects are not supported for WebSocket requests.

Starting from Chrome 72, an extension will be able to intercept a request only if it has host permissions to both the requested URL and the request initiator.

Starting from Chrome 96, the webRequest API supports intercepting the WebTransport over HTTP/3 handshake request. Since the handshake is done by means of an HTTP CONNECT request, its flow fits into HTTP-oriented webRequest model. Note that:

Request IDs

Each request is identified by a request ID. This ID is unique within a browser session and the context of an extension. It remains constant during the life cycle of a request and can be used to match events for the same request. Note that several HTTP requests are mapped to one web request in case of HTTP redirection or HTTP authentication.

Registering event listeners

To register an event listener for a web request, you use a variation on the usual addListener() function. In addition to specifying a callback function, you have to specify a filter argument, and you may specify an optional extra info argument.

The three arguments to the web request API's addListener() have the following definitions:

var callback = function(details) {...};
var filter = {...};
var opt_extraInfoSpec = [...];

Here's an example of listening for the onBeforeRequest event:

chrome.webRequest.onBeforeRequest.addListener(
    callback, filter, opt_extraInfoSpec);

Each addListener() call takes a mandatory callback function as the first parameter. This callback function is passed a dictionary containing information about the current URL request. The information in this dictionary depends on the specific event type as well as the content of opt_extraInfoSpec.

If the optional opt_extraInfoSpec array contains the string 'blocking' (only allowed for specific events), the callback function is handled synchronously. That means that the request is blocked until the callback function returns. In this case, the callback can return a webRequest.BlockingResponse that determines the further life cycle of the request. Depending on the context, this response allows canceling or redirecting a request (onBeforeRequest), canceling a request or modifying headers (onBeforeSendHeaders, onHeadersReceived), and canceling a request or providing authentication credentials (onAuthRequired).

If the optional opt_extraInfoSpec array contains the string 'asyncBlocking' instead (only allowed for onAuthRequired), the extension can generate the webRequest.BlockingResponse asynchronously.

The webRequest.RequestFilter filter allows limiting the requests for which events are triggered in various dimensions:

URLs
URL patterns such as *://www.google.com/foo*bar.
Types
Request types such as main_frame (a document that is loaded for a top-level frame), sub_frame (a document that is loaded for an embedded frame), and image (an image on a web site). See webRequest.RequestFilter.
Tab ID
The identifier for one tab.
Window ID
The identifier for a window.

Depending on the event type, you can specify strings in opt_extraInfoSpec to ask for additional information about the request. This is used to provide detailed information on request's data only if explicitly requested.

Handling authentication

To handle requests for HTTP authentication, add the "webRequestAuthProvider" permission to your manifest file:

{
  "permissions": [
    "webRequest",
    "webRequestAuthProvider"
  ]
}

Note that this permission is not required for a policy installed extension with the "webRequestBlocking" permission.

To provide credentials synchronously:

chrome.webRequest.onAuthRequired.addListener((details) => {
    return {
      authCredentials: {
        username: 'guest',
        password: 'guest'
      }
    };
  },
  { urls: ['https://httpbin.org/basic-auth/guest/guest'] },
  ['blocking']
);

To provide credentials asynchronously:

chrome.webRequest.onAuthRequired.addListener((details, callback) => {
    callback({
      authCredentials: {
        username: 'guest',
        password: 'guest'
      }
    });
  },
  { urls: ['https://httpbin.org/basic-auth/guest/guest'] },
  ['asyncBlocking']
);
Implementation details

Several implementation details can be important to understand when developing an extension that uses the web request API:

web_accessible_resources

When an extension uses webRequest APIs to redirect a public resource request to a resource that is not web accessible, it is blocked and will result in an error. The above holds true even if the resource that is not web accessible is owned by the redirecting extension. To declare resources for use with declarativeWebRequest APIs, the "web_accessible_resources" array must be declared and populated in the manifest as documented here.

Conflict resolution

In the current implementation of the web request API, a request is considered canceled if at least one extension instructs to cancel the request. If an extension cancels a request, all extensions are notified by an onErrorOccurred event. Only one extension can redirect a request or modify a header at a time. If more than one extension attempts to modify the request, the most recently installed extension wins, and all others are ignored. An extension is not notified if its instruction to modify or redirect has been ignored.

Caching

Chrome employs two caches—an on-disk cache and a very fast in-memory cache. The lifetime of an in-memory cache is attached to the lifetime of a render process, which roughly corresponds to a tab. Requests that are answered from the in-memory cache are invisible to the web request API. If a request handler changes its behavior (for example, the behavior according to which requests are blocked), a simple page refresh might not respect this changed behavior. To ensure the behavior change goes through, call handlerBehaviorChanged() to flush the in-memory cache. But don't do it often; flushing the cache is a very expensive operation. You don't need to call handlerBehaviorChanged() after registering or unregistering an event listener.

Timestamps

The timestamp property of web request events is only guaranteed to be internally consistent. Comparing one event to another event will give you the correct offset between them, but comparing them to the current time inside the extension (via (new Date()).getTime(), for instance) might give unexpected results.

Error handling

If you try to register an event with invalid arguments, then a JavaScript error will be thrown, and the event handler will not be registered. If an error is thrown while an event is handled or if an event handler returns an invalid blocking response, an error message is logged to your extension's console, and the handler is ignored for that request.

Examples

The following example illustrates how to block all requests to www.evil.com:

chrome.webRequest.onBeforeRequest.addListener(
  function(details) {
    return {cancel: details.url.indexOf("://www.evil.com/") != -1};
  },
  {urls: ["<all_urls>"]},
  ["blocking"]
);

As this function uses a blocking event handler, it requires the "webRequest" as well as the "webRequestBlocking" permission in the manifest file.

The following example achieves the same goal in a more efficient way because requests that are not targeted to www.evil.com do not need to be passed to the extension:

chrome.webRequest.onBeforeRequest.addListener(
  function(details) { return {cancel: true}; },
  {urls: ["*://www.evil.com/*"]},
  ["blocking"]
);

The following example illustrates how to delete the User-Agent header from all requests:

chrome.webRequest.onBeforeSendHeaders.addListener(
  function(details) {
    for (var i = 0; i < details.requestHeaders.length; ++i) {
      if (details.requestHeaders[i].name === 'User-Agent') {
        details.requestHeaders.splice(i, 1);
        break;
      }
    }
    return {requestHeaders: details.requestHeaders};
  },
  {urls: ["<all_urls>"]},
  ["blocking", "requestHeaders"]
);

To try the chrome.webRequest API, install the webRequest sample from the chrome-extension-samples repository.

Types

BlockingResponse

Returns value for event handlers that have the 'blocking' extraInfoSpec applied. Allows the event handler to modify network requests.

Properties

FormDataItem

Contains data passed within form data. For urlencoded form it is stored as string if data is utf-8 string and as ArrayBuffer otherwise. For form-data it is ArrayBuffer. If form-data represents uploading file, it is string with filename, if the filename is provided.

An array of HTTP headers. Each header is represented as a dictionary containing the keys name and either value or binaryValue.

Properties Enum

"redirect"

"request_headers"

"response_headers"

"auth_credentials"

Enum

"responseHeaders"
Specifies that the response headers should be included in the event.

"blocking"
Specifies the request is blocked until the callback function returns.

"asyncBlocking"
Specifies that the callback function is handled asynchronously.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"responseHeaders"
Specifies that the response headers should be included in the event.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"blocking"
Specifies the request is blocked until the callback function returns.

"requestBody"
Specifies that the request body should be included in the event.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"requestHeaders"
Specifies that the request header should be included in the event.

"blocking"
Specifies the request is blocked until the callback function returns.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"responseHeaders"
Specifies that the response headers should be included in the event.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"blocking"
Specifies the request is blocked until the callback function returns.

"responseHeaders"
Specifies that the response headers should be included in the event.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"responseHeaders"
Specifies that the response headers should be included in the event.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

Enum

"requestHeaders"
Specifies that the request header should be included in the event.

"extraHeaders"
Specifies that headers can violate Cross-Origin Resource Sharing (CORS).

RequestFilter

An object describing filters to apply to webRequest events.

Properties Enum

"main_frame"
Specifies the resource as the main frame.

"sub_frame"
Specifies the resource as a sub frame.

"stylesheet"
Specifies the resource as a stylesheet.

"script"
Specifies the resource as a script.

"image"
Specifies the resource as an image.

"font"
Specifies the resource as a font.

"object"
Specifies the resource as an object.

"xmlhttprequest"
Specifies the resource as an XMLHttpRequest.

"ping"
Specifies the resource as a ping.

"csp_report"
Specifies the resource as a Content Security Policy (CSP) report.

"media"
Specifies the resource as a media object.

"websocket"
Specifies the resource as a WebSocket.

"webbundle"
Specifies the resource as a WebBundle.

"other"
Specifies the resource as a type not included in the listed types.

UploadData

Contains data uploaded in a URL request.

Properties Properties

MAX_HANDLER_BEHAVIOR_CHANGED_CALLS_PER_10_MINUTES

The maximum number of times that handlerBehaviorChanged can be called per 10 minute sustained interval. handlerBehaviorChanged is an expensive function call that shouldn't be called often.

Methods

handlerBehaviorChanged()

chrome.webRequest.handlerBehaviorChanged(): Promise<void>

Needs to be called when the behavior of the webRequest handlers has changed to prevent incorrect handling due to caching. This function call is expensive. Don't call it often.

Events

onActionIgnored

chrome.webRequest.onActionIgnored.addListener(
  callback: function,
)

Fired when an extension's proposed modification to a network request is ignored. This happens in case of conflicts with other extensions.

Parameters

onAuthRequired

chrome.webRequest.onAuthRequired.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnAuthRequiredOptions[],
)

Fired when an authentication failure is received. The listener has three options: it can provide authentication credentials, it can cancel the request and display the error page, or it can take no action on the challenge. If bad user credentials are provided, this may be called multiple times for the same request. Note, only one of 'blocking' or 'asyncBlocking' modes must be specified in the extraInfoSpec parameter.

Parameters

onBeforeRedirect

chrome.webRequest.onBeforeRedirect.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnBeforeRedirectOptions[],
)

Fired when a server-initiated redirect is about to occur.

Parameters

onBeforeRequest

chrome.webRequest.onBeforeRequest.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnBeforeRequestOptions[],
)

Fired when a request is about to occur.

Parameters
chrome.webRequest.onBeforeSendHeaders.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnBeforeSendHeadersOptions[],
)

Fired before sending an HTTP request, once the request headers are available. This may occur after a TCP connection is made to the server, but before any HTTP data is sent.

Parameters

onCompleted

chrome.webRequest.onCompleted.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnCompletedOptions[],
)

Fired when a request is completed.

Parameters

onErrorOccurred

chrome.webRequest.onErrorOccurred.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnErrorOccurredOptions[],
)

Fired when an error occurs.

Parameters
chrome.webRequest.onHeadersReceived.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnHeadersReceivedOptions[],
)

Fired when HTTP response headers of a request have been received.

Parameters

onResponseStarted

chrome.webRequest.onResponseStarted.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnResponseStartedOptions[],
)

Fired when the first byte of the response body is received. For HTTP requests, this means that the status line and response headers are available.

Parameters
chrome.webRequest.onSendHeaders.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnSendHeadersOptions[],
)

Fired just before a request is going to be sent to the server (modifications of previous onBeforeSendHeaders callbacks are visible by the time onSendHeaders is fired).

Parameters

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-11 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-11 UTC."],[],[]]


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4