Currently there is no way to distinguish XHR requests from other requests, yet it may be very useful for ad blocking. For instance, ad blocking on speedtest.net involves blocking scripts and XHR requests |http://$script,xmlhttprequest,domain=speedtest.net |https://$script,xmlhttprequest,domain=speedtest.net
<rdar://problem/49841405>
I assume this would still package xhr and fetch together, right? We wouldn't want to block xhr but not fetch.
Hi Alex, I can't think of any case when distinguishing fetch from xhr would be useful.
What type do XHR and Fetch currently show up as? "raw"? Or are they not blockable?
They show up as "raw".
I guess it's worthwhile to distinguish from other "raw" types such as WebSockets? Perhaps every distinct use of "raw" should also have a more specific type. (For compatibility reasons "raw" would likely remain defined as it is currently.)
> I guess it's worthwhile to distinguish from other "raw" types such as WebSockets? Perhaps every distinct use of "raw" should also have a more specific type. (For compatibility reasons "raw" would likely remain defined as it is currently.) To be honest, I wanted to request a distinct request type for websocket as well. WebSockets are often used by adblocking circumvention scripts and this would be really useful to be able to distinguish them. For instance, there are a couple of rules in EasyList that block WebSocket connections on >300 websites.
Oh, and there's another feature request - about "subdocument" resource type: https://bugs.webkit.org/show_bug.cgi?id=153559 Should I merge them all in one? The final list of resource types we'd like to have is: * "subdocument" -- for non-top-level frames * "xmlhttprequest" -- fetch/xhr * "websocket"
No need to merge (unless somebody wants to add all of them in a single patch). If anyone wants to post a patch for this, some thoughts: - The type should probably be named "fetch" rather than "xmlhttprequest", better to name it after the modern API than the legacy version. - We likely need to keep "raw" matching everything it does not, so the xhr/fetch and web socket types would have to be synonyms for subsets of "raw". I believe we already did this with "ping", so there should be an example to follow. - Same thing for "subdocument" being a subset of "document" (maybe this means we would need a separate "main-document"?)
*** This bug has been marked as a duplicate of bug 222709 ***