blob urls are meaningless outside of the frame that created it (I think?), so I'm not sure if app can do anything useful, except to block all blob urls or replace it with the same content that doesn't depend on the url itself.

probably ok to just not intercept them at all, since no one has complained

In general I don't think it really makes any sense to issue shouldInterceptRequest for things that aren't network requests :)

There's three general categories of use of this callback:
1) replacing network resources with locally cached resources
2) blocking network loads
3) communicating state from the page to the app by navigating to magic URLs

and it doesn't seem like any of these are likely to be used for blob: or data: or other "data-bearing" schemes. I suspect the chrome extension webRequest APIs also don't trigger for data and blob.

So if there's no sign that this is breaking anyone, I think we should jsut leave it alone as Bo says.

> In general I don't think it really makes any sense to issue shouldInterceptRequest for things that aren't network requests :)

Well, we already invoke shouldInterceptRequest for data URLs... and now loadDataWithBaseURL ( issue 769126 ). So perhaps "network" isn't the best rule of thumb for the API.

Also, I thought we agreed on issue 821140 that this should *not* be used to block network loads, because the app's only alternative is to crash. Did I misunderstand?

---

As for blob URLs, I'm also fine with ignoring them wrt shouldInterceptRequest, glad others agree with me. I'll land a CL to update the comment in the code, because this is no longer a PlzNavigate workaround, but an intentional API decision. And I'll document this in http://b/74841041.

This *shouldn't* be used to block network loads, but it's also the only way to even attempt to do that, so since there's no alternative we pretty much have to make this case work as well as it can within the API. You can "block" requests by returning empty responses, which doesn't result in actual network errors and so has bad behaviour, but still stops the network request from occurring. You don't have to crash, you just *do* crash if you try to block the request by throwing an exception.

I don't think we *should* invoke it for data URLs, but the ship probably sailed on that already and I suspect we'd break more people if we stopped. Maybe worth an experiment/UMA stat sometime :)

I think a valid point here is that blob URLs are actually meaningless outside of their context and so it's impossible for the app to make any kind of meaningful decision about what to do with them - at least data URLs *contain* their meaning, and so if the app really wants to read the contents of the URL it could.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cfef8b58deef2fcfc782393e9915187d1913300a

commit cfef8b58deef2fcfc782393e9915187d1913300a
Author: Nate Fischer <ntfschr@chromium.org>
Date: Tue Mar 20 22:32:30 2018

AW: clarify comment regarding shouldInterceptRequest

No change to behavior, only a comment change.

This clarifies that we intentionally do not emit shouldInterceptRequest
for any blob URLs, because the application cannot use the callback for
anything useful. See bug for more discussion.

Bug:  822983 
Test: N/A
Change-Id: Iba9a03575ff3e1f5d14ada5ca8256929afd7db71
Reviewed-on: https://chromium-review.googlesource.com/972193
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544569}
[modify] https://crrev.com/cfef8b58deef2fcfc782393e9915187d1913300a/android_webview/browser/net/aw_request_interceptor.cc

Marking this bug as fixed, since we're all in agreement regarding blob URLs.

I agree with everything re #4, although we might consider adding an API to *actually* block network requests, without all of shouldInterceptRequest's problems.

Please add the verification steps to verify in 67 fixes

Bulk edit: marking stale 'fixed' bugs as 'verified' since they don't need verification at this point.