New chrome.experimental.webRequest API

[Michael Gundlach]

Hi!  I'm the author of AdBlock.  The upcoming webRequest API is exciting because AdBlock will finally be able to (reliably and simply) block resources from downloading.  (Right now I use a hack that loads AdBlock's whole filtering engine into every content script -- which uses tons of RAM and can miss the first few resources on the page.)

I looked over the webRequest API and have some early feedback [I know, nobody has requested it, but I'm super excited about this API being great :)  ]:

1) If I read onBeforeRequest correctly, it doesn't currently fire for Flash object subrequests.  Am I wrong?  AdBlock would need this in order to block in-video and in-game Flash ads.

2) onBeforeRequest also doesn't seem to fire for XmlHttpRequests.  If not, I could make a website whose <script src=""> and <link href=""> tags were undetectable by onBeforeRequest, by fetching data via XHR and plopping the data into a <script> or <style> tag inline in the document.

Could we please add support for both of those?  Maybe the onBeforeRequest callback's details.type values could be "object_subrequest" and "xmlhttprequest" respectively.

In addition, I've got some suggestions that AdBlock isn't depending on like #1 and #2, but might make the API better for other developers:

3) onCompleted includes the url from onBeforeRequest but not the tabId, method, or type.  If we're going to include the url as a convenience so people don't have to store the requestId, why not be symmetrical and provide the tabId, method, and type as well?

4) It onBeforeRequest, onHeadersReceived, and onCompleted exposed the request headers, response headers, and response body respectively, they would be more powerful.  Perhaps there are security implications with exposing the headers [which hold cookies for 3rd party sites] and those could be hidden if the extension doesn't have cookies permisson?

5) If the request/response headers & body could be _modified_ by the on-* events, that would make them even more powerful.  Maybe the chrome.experimental.proxy API already serves this purpose?  Maybe this is a bad idea because script code that took a long time to synchronously modify headers/bodies would slow down Chrome?

Thanks for listening -- this is the API I've been waiting for since last December!

Michael

[Eric Wong]

I'm reading over the documentation at
http://code.google.com/chrome/extensions/trunk/experimental.webRequest.html
but I don't see how this would change anything for AdBlock since
webRequest doesn't have any way to stop an event from happening. Or am
I missing something here and it's not documented?

[Pam Greene]

You're right, this initial work is notification-only and won't change anything for AdBlock. See the "Synchronous (blocking) notifications?" section of the API proposal at

http://dev.chromium.org/developers/design-documents/extensions/notifications-of-web-request-and-navigation

for early thoughts on extending it to allow modifications too.

- Pam

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.