WebExtension - WebRequest: it should be possible to cancel or redirect data-URL requests
Categories
(WebExtensions :: Request Handling, defect, P3)
Tracking
(Not tracked)
People
(Reporter: bugzilla, Unassigned)
References
Details
Attachments
(1 file)
|
562 bytes,
application/zip
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180705213349 Steps to reproduce: When using browser.webRequest.onBeforeRequest with blocking it should be possible to cancel or redirect data-URLs. There is even a "FIXME" comment in the webRequest-Code with this issue... https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/addons/WebRequest.jsm#250 Reproduction scenario: - install the provided webExtension temporarily - go to https://itty.bitty.site/#/data:text/html;base64,PGh0bWw+PGJvZHk+PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLm9yZyI+Y2xpY2s8L2E+PC9ib2R5 PjwvaHRtbD4= Actual results: The browser console shows that the webExtension found a data-URL and tried to redirect it. But the iFrame displays the data-URLs content and not example.org. Expected results: The data-URL content is shown.
|
||
Updated•6 years ago
|
|
||
Comment 1•6 years ago
|
||
This doesn't work because synchronous handling of non-http* requests was removed (necessarily). We'll probably need a larger effort at rewrite of webrequestcontent and possibly various channels/etc. to make this possible. So while we should do something here, it's potentially a larger project.
|
|
||
Updated•6 years ago
|
|
||
Comment 2•5 years ago
|
||
I ran into this issue, struggled with it, and updated the documentation to reflect the current limitations on non-HTTP(S) protocols on the webRequest MDN page.
Is there currently any kind of workaround available to modify the request in any way? I make an extension that blocks NSFW images and right now my working but highly unfortunate alternative is to intercept and scan text/html via regex for base64 image URLs.
|
|
||
Comment 3•5 years ago
|
||
webRequest is tightly bound to http channels, other protocols just don't work the same. The only alternative I can think of off the top of my head is to use a content script to detect images using data urls.
|
|
||
Comment 4•4 years ago
|
||
I was just doing a bit of backlog management today and remembered this issue, so figured I would link it here. Tracking this bug in my project due to this limitation: https://github.com/wingman-jr-addon/wingman_jr/issues/18
Should this bug be closed?
Because the feature to observe data urls has been removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1631933
|
||
Comment 6•4 years ago
|
||
I'll wait until bug 1631933 reached the release channel. If there is zero interest in data:-URLs, then we can close this bug.
Otherwise we can convert this to an open feature request.
There is interest in data-URLs. I have to use CSP headers in CanvasBlocker to prevent fingerprinting over these (https://github.com/kkapsner/CanvasBlocker/issues/208) which causes several other problems (e.g. https://github.com/kkapsner/CanvasBlocker/issues/214) directly blocking would be much better.
Better for this issue would be if https://bugzilla.mozilla.org/show_bug.cgi?id=1475831 would be fixed though...
|
|
||
Comment 8•4 years ago
|
||
(In reply to kkapsner from comment #7)
Better for this issue would be if https://bugzilla.mozilla.org/show_bug.cgi?id=1475831 would be fixed though...
Definitely... The network level (data:-URLs) is not the right place for your use case. Extensions should be able to run content script in any web page that extensions can load. That's not just data:, but also blob: and sandboxed origins. It's a pet peeve of mine but I haven't got to fix it yet.
|
|
||
Comment 9•3 years ago
|
||
Closing bug since data:-URLs are not supported, and there hasn't been a compelling reason to support it again (in particular hardly anyone noticed that the feature disappeared). I've removed the notice from the webRequest docs at https://github.com/mdn/content/pull/5150
Description
•