Bug 154811
| Summary: | Feature request: add "xmlhttprequest" resource type for content blockers | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Andrey Meshkov <am> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | achristensen, benjamin, krzysztof.modras, mjs, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Andrey Meshkov
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/49841405>
Alex Christensen
I assume this would still package xhr and fetch together, right? We wouldn't want to block xhr but not fetch.
Andrey Meshkov
Hi Alex, I can't think of any case when distinguishing fetch from xhr would be useful.
Maciej Stachowiak
What type do XHR and Fetch currently show up as? "raw"? Or are they not blockable?
Andrey Meshkov
They show up as "raw".
Maciej Stachowiak
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.)
Andrey Meshkov
> 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.
Andrey Meshkov
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"
Maciej Stachowiak
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"?)
Alex Christensen
*** This bug has been marked as a duplicate of bug 222709 ***