Closed Bug 1821303 Opened 2 years ago Closed 2 years ago

[DNR] Match POST requests of ancestor frames in allowAllRequests

Categories

(WebExtensions :: Request Handling, enhancement, P3)

enhancement

Tracking

(firefox113 fixed)

RESOLVED FIXED
113 Branch
Tracking Status
firefox113 --- fixed

People

(Reporter: robwu, Assigned: robwu)

References

Details

(Whiteboard: [addons-jira])

Attachments

(3 files)

Severity: -- → N/A
Priority: -- → P3
Whiteboard: [addons-jira]

Add activeSessionHistoryEntry attribute to CanonicalBrowsingContext to
expose the existing implementation of
CanonicalBrowsingContext::GetActiveSessionHistoryEntry.

To avoid unnecessary cloning of nsIInputStream, add a hasPostData
boolean attribute to tell whether a nsISHEntry has populated postData.

It isn't very obvious to me what this bug is about.
Why does extension code need to deal with session history?
What is DNR? :)

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #4)

It isn't very obvious to me what this bug is about.
Why does extension code need to deal with session history?
What is DNR? :)

declarativeNetRequest (DNR) is a declarative API to allow extensions to specify rules (conditions + actions) describing how network requests should be handled. It is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/declarativeNetRequest.
DNR was originally designed by Google as a replacement for the webRequest API, which is notably used by the class of content blocker extensions (aka ad blockers). While we maintain support for blocking WebRequest in MV3, we also ship support for declarativeNetRequest for compatibility reasons.

When a navigation request matches a rule with the "allowAllRequests" action, the desired result is for other rules to be ignored (not only for that specific request but also future subresource requests). Or said differently: if the outcome for a request is to block/redirect/etc a request, we need to check whether there are any applicable "allowAllRequest" rules among the frame ancestors that would override the request. In order to determine this, the request for the navigations in the ancestor frames needs to be reconstructed. And one of the conditions is the HTTP method.

With that context, I can finally explain why "session history" is relevant here. It is merely a means to a goal. It is a way to determine whether a document is associated with a POST form submission (opposed to a regular GET navigation). Due to the SHIP work, the SessionHistoryEntry (nsISHEntry) in the parent offers the information needed to determine whether a request had been a POST submission.
I figured that it would be a reliable primitive to use, because the information was already maintained to support the form submission confirmation UI upon reload ("To display this page, Nightly must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.").

Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/84cd09689228 Add getter for activeSessionHistoryEntry to BC r=peterv https://hg.mozilla.org/integration/autoland/rev/90c73fb01441 Detect POST in condition for allowAllRequests action r=rpl,peterv https://hg.mozilla.org/integration/autoland/rev/f474edf390d1 Add hasPostData bool to nsISHEntry r=smaug

Backed out for causing xpcshell failures on test_ext_dnr_allowAllRequests.js.

Flags: needinfo?(rob)

Backed out because the test failed when Fission was disabled in a test configuration for Android. The method to determine the POST method requires SHIP (Session History in Parent), which is disabled when Fission is turned off.

Flags: needinfo?(rob)
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/4b06082fe51b Add getter for activeSessionHistoryEntry to BC r=peterv https://hg.mozilla.org/integration/autoland/rev/c7c7319e6f40 Detect POST in condition for allowAllRequests action r=rpl,peterv https://hg.mozilla.org/integration/autoland/rev/a849087c16f9 Add hasPostData bool to nsISHEntry r=smaug
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: