2

I am developing an extension for blocking downloading by file's Content-Type. This is part of background script which handle headers receiving:

chrome.webRequest.onHeadersReceived.addListener(function(details) {
    var headers = details.responseHeaders;

    for(var i = 0, l = headers.length; i < l; ++i) {
        if(headers[i].name == "Content-Type" && headers[i].value == "<some_type>") {
            return {cancel: true};
        }
    }
}, {urls: ["<all_urls>"]}, ["responseHeaders", "blocking"]);

And I get page with error message: message

So I need some solution to keep user on previous page without reloading to displaying this error page OR somehow move back from this service page after it displayed.

mmatviyiv
  • 111
  • 1
  • 1
  • 9

1 Answers1

2

If you wish to prevent navigating away in an (i)frame based on the content type, then you're out of luck - it is not possible to prevent a page from unloading at this point.

If you want to prevent the top-level frame from navigating away, then there's hope. You can redirect the page to a resource that replies with HTTP status code 204.

chrome.webRequest.onHeadersReceived.addListener(function(details) {
    // ... your code that checks whether the request should be blocked ...

    if (details.frameId === 0) { // Top frame, yay!
        var scheme = /^https/.test(details.url) ? "https" : "http";
        chrome.tabs.update(details.tabId, {
            url: scheme + "://robwu.nl/204"
        });
        return;
    }
    return {cancel: true};
}, {
    urls: ["<all_urls>"],
    types: ["main_frame", "sub_frame"]
}, ["responseHeaders", "blocking"]);

Once issue 280464 is solved, the previous method can also be used to prevent unloads in subframes.

https://robwu.nl/204 is part of my website. Access to this URL is not logged. The response to this entry will always be "204 No Content".

Rob W
  • 341,306
  • 83
  • 791
  • 678
  • @RobW the given solution is not preventing the download, using just "return" causes the download to start. – adnan kamili Mar 23 '14 at 14:14
  • @adnankamili To fix that issue, you could change the `content-type` header to something non-downloadable text/plain, add `content-type-options: no-sniff` (to disable MIME-sniffing). Though honestly, this answer is a real hack. If your intent is to cancel a request, then you should really be using `{cancel: true}`. – Rob W Mar 23 '14 at 14:25
  • @RobW Still no luck, I can't use {cancel: true} because it causes that block page to appear. I tried return {redirectUrl: ""};, this prevents the weblock page but the function does not return and extension keeps on waiting. Can you suggest some other hack as I need it desperately. – adnan kamili Mar 23 '14 at 14:49
  • `redirectUrl` is not supported yet (though I'm working on an implementation, see http://crbug.com/280464#4 for details). Further, a bug in Chromium prevented the request from completing when you supply it (see http://crbug.com/348417, fixed in Chrome 35). My previously suggested hack (modifying the headers to use `Content-Type: text/plain` and `X-Content-Options: nosniff`) should work. If it didn't, then you need to show your code. – Rob W Mar 23 '14 at 14:54
  • @RobW I have opened a new question with code http://stackoverflow.com/questions/22593735/how-to-prevent-download-on-recieving-response-headers-in-chrome-extension also tried a hack involving change in response line 302 Moved Temporarily but it didn'work – adnan kamili Mar 23 '14 at 16:43