Description
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!