Instead of "example/path1" use "example.com/path1"

I'll defer to the policy owners on whether this is desired behavior, but currently, in terms of requests with responses sent to the renderer process, the blacklist is only applied to frame navigations (Main frames and subframes).

This is probably the same problem as crbug.com/691125.

Unfortunately its working as intended. Steps followed.

1. Server: 
   Set the policy value : youtube/channel in "Block access to a list of 
   URLs"
2. Client:Navigated to 
    https://www.youtube.com/channel/, 
    https://www.youtube.com/,
    https://youtube/channel 

Observed : All the above links are blocked, which is expected.
OS: Win 7 client , Win 2012 Server
Chrome Version: 57.0.2987.98

Also looping to enterprise experts for further updates.

I do not understand the Comment #4 and its relevancy to this discussion.

Hi admin,

I know you are giving a rather generic example and your concrete urls might look differenly but I still have to ask this - are you specifying the urls to be blocked according to the guidelines here https://www.chromium.org/administrators/url-blacklist-filter-format ?

Best,
Julian 

+cyrus/dskaram - from a product standpoint, we enforce URL blacklists on top level URLs and frames, but not on individual XHR requests or requests using extension socket APIs, etc. I suspect it also doesn't apply to subresource requests (so, images, JS blobs, etc) but we'd have to verify this.

Should we change this behavior to include XHR requests and other subresource requests? Or leave it as-is to cover only frames? I don't think we know currently whether changing this behavior would break sites because we don't know how many subresource requests are being allowed through that would otherwise be blocked.

Hi Drew - my take is, yes, if easy, we should have the blacklist apply to as many things as possible - in fact, ideally, no network traffic of any kind should be allowed to go to those URL patterns -- so question is what is LOE on this?

I would even claim this to be a regression. I verified that this is indeed the case btw so flipping it to untriaged and upping the prio. However I doubt this fix will go in 56 or 57 as it will be extensive.

I am pretty sure when this policy was built it was preventing all kinds of requests. Could also be my weak memory though. :)

I think it's intended behavior that the URLBlacklist only applies to top level URLs and frames. If you want more granular control over blocking XHR you are free to get it by having a force installed extension use chrome.webRequest

+ pastarmovj@chromium.org
yes