In Bug #117678, I'm requesting that GTK expose the reason for a request so that AdBlockPlus can be fully implemented[1]. After digging, I see that this information is not available. [1]https://adblockplus.org/en/filters#options
Created attachment 225866 [details] Add-a-reason-field-to-ResourceRequest Initial patch attached. I'm not sure which 'reasons' could/should be merged together (or split). This doesn't change any call sites or method signatures (another patch goes through the repo and adds reason parameters and updates callers).
Comment on attachment 225866 [details] Add-a-reason-field-to-ResourceRequest This looks like a layering violation to me. A ResourceRequest shouldn't know about what it's for. Can't this be put on the ResourceLoader level? There's also no rationale for why this is needed at all.
Feature rationale: I work on uzbl[1] and I'd like to implement support for AdBlockPlus filter rules[2] for adblocking. The problem is that the rules specify that, e.g., they only apply for images, JS, or CSS files which WebKit doesn't offer at all. I'd also like to put some auditing in to drive the Lightbeam[3] code in uzbl. Location: ResourceRequest seemed like the best place since the ResourceLoader would otherwise need to get the information through some other path in places and notification of the reason would likely come through changed notification APIs (e.g., willSendRequest would need a reason parameter added to it). In WebKit2, the reason would need to get back to the UIProcess somehow and it seemed to fit there as well. I can try to take a stab at moving it into the loader(s) itself. [1]http://uzbl.org [2]https://adblockplus.org/en/filters#options [3]https://en.wikipedia.org/wiki/Lightbeam_%28software%29
Another rationale for going into ResourceRequest is that the referrer is there, which is arguably another "reason" the request is being made.