Skip to content

Proposal: declarativeNetRequest: matching based on response headers #460

Closed
@Celsius273

Description

@Celsius273

Hello!

My name is Kelvin Jiang and I am part of the Chrome Extensions team and I'll be working on adding the ability for declarativeNetRequest (DNR) rules to match based on response headers which is tracked in this crbug

From what I've gathered (requirements):

Add the ability to match on:

  • the existence of a response header
  • the non-existence of a response header
  • if a given response header includes/does not include a specified value

^to support this, I propose adding the following fields to RuleCondition:

// New type
HeaderCondition {
  // The name of the header.
  string header;
  
  // If specified, match this condition if the header's value contains at least one element in this list
  string[]? values; 
 
  // If specified, do not match this condition if the header exists but its value contains at least one element in this list.
  string[]? excludedValues;
}

RuleCondition: {
  // add the following 2 fields (below):

  // rule matches if the request matches any one condition in this list (if specified)
  HeaderCondition[]? responseHeaders;
  
  // rule does not match if the request matches any one condition in this list (if specified)
  // This is essentially a negation of responseHeaders above
  HeaderCondition[]? excludedResponseHeaders; 
}

Context: request stage for webRequest and DNR

Currently, DNR rules are matched during the onBeforeRequest stage. For rules that match on response headers, the earliest stage that they can be matched is onHeadersReceived when we receive the response headers from the request.

A few more details:

  • DNR actions that happen during the onBeforeRequest stage (block/redirect) will prevent the request from proceeding to the onHeadersReceived stage and so it will not get matched based on response headers
  • ^this means that rule priorities only pertain to the request stage that the rule will get matched in
  • rules that match on response headers cannot modify request headers (since the request headers have already been sent in an earlier request stage)
  • rules that match on response headers will examine headers in the onHeadersReceived stage BEFORE they are modified by the webRequest API or any other DNR rules (like modifyHeaders rules that were matched in the onBeforeRequest stage)
  • matching based on value/excludedValues will be case insensitive

Let me know if this looks good or if there should any changes to the above proposal. I'm looking forward to working with all of you and I know that this feature has been requested for quite a while!

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions