Hi Eric, Thanks for the detailed feedback, much appreciated. One problem with making the proxy API programmatic rather than declarative is that an extension could slow down or even block page rendering. Almost all our existing APIs are asynchronous for this reason.
What are the most common use cases for this kind of logic? Can those be handled in a declarative way? -Nick On Mon, Aug 17, 2009 at 6:28 AM, [email protected] <[email protected]>wrote: > > Hi Eric, > > I'm the author of FoxyProxy. I'm very glad to see this proposal in the > works for Chrome. I look forward to porting FoxyProxy as soon as > possible. I have a number of thoughts about the proposal but, lacking > time to enumerate them all right now, I'd like to write down a few off- > the-cuff. > > 1. The decision about which proxy settings to use to load URLs would, > IMHO, best be made in a callback function rather than a list of static > rules/patterns. In other words, something like this: > > chrome.proxy.useCustomProxySettings(function(tab) { > /** > * This function is called by Chrome when a tab wants to load a URL. > * > * The |tab| argument contains properties about the tab wanting to a > load a URL: > * .uri is the URI to be loaded > * .index is the 0-based index of the tab in the tablist (how to > determine LTR/RTL?) > * maybe other stuff > * > * If no tab is associated with the loading URL (e.g., bookmarked > RSS feeds), |tab| is null. > * > * This function should return one of the following: > * 1. a ProxyServer object > * 2. The constant chrome.proxy.DIRECT to use no proxy > * 3. The constant chrome.proxy.SYSTEM to use the system's proxy > settings > * > */ > var now = new Date(); > return now.getDay() == 0 || now.getDay() == 1 ? new ProxyServer > ("http://foo.com:8080";) : new ProxyServer("socks://foo.com:1080"); > } > ); > > I hope you can see how this is more dynamic than an array of strings. > Gecko uses this approach: > > http://mxr.mozilla.org/mozilla1.9.1/source/netwerk/base/public/nsIProtocolProxyFilter.idl#53 > . > The extension implements that interface. Gecko calls the extension's > applyFilter() function and uses the returned structure to identify the > proxy to use for loading. However, the key piece of information > missing in this interface is tab-related data. "Tab-per-proxy" is the > holy grail for FoxyProxy, but there is currently no reliable way to > determine the tab in question from the nsIProtocolProxyFilter > interface, and that is why "tab-per-proxy" doesn't exist in FoxyProxy. > And that's also why I've included |tab| as an argument here. > > Another point to consider is this approach eliminates the need for: > a. the ProxyRules structure > b.the ProxySettings structure > , simplifying the complexity of this proposal. > > Another example: > > chrome.proxy.useCustomProxySettings(function(tab) { > if (tab == null) return chrome.proxy.SYSTEM; /* system proxy > settings */ > /* No proxy for PAC files. This really should be a regex to > ensure .pac is the final part of the URL and not e.g., > http://foo.com/bar.pac/index.html */ > if (tab.url.indexOf(".pac") > 0) return chrome.proxy.DIRECT; > if (tab.index == 3 || tab.title == "Gmail" || tab.url.indexOf > ("http://bar.com";) == 0) return new ProxyServer("socks://baz:1080"); > return new ProxyServer("http://boo:8080";); > }); > > 2. It would be nice if the ProxyServer object accepted URI strings. > Perhaps this is already implied by |constructor(string spec)|, but to > elaborate here are some examples: > > * http://foo.com:8080 (implies an HTTP proxy) > * socks5://foo.com:1080 (implies a SOCKS5 proxy) > * socks4a://foo.com:1080 (implies a SOCKS4a proxy) > * socks://username:[email protected]:1080 (implies a SOCKS5 > proxy with authentication; I realize this isn't yet supported by > Chrome) > * pac+http://foo.com/proxy.pac (use the specified PAC file) > * pac+https://foo.com/proxy.pac (use the specified PAC file but > load it over https) > * data:function%20FindProxyByURL(url%2C%20host)%20%7Breturn > %20'PROXY%20foo.com%3A80'%3B%20return%20'DIRECT'%3B%7D (URL-encoded > inline PAC) > > The last example can be encoded using Javascript's native escape() > function. With the last 3 examples in mind, the need for the > PacScript struct is obviated, simplifying the proposal even further. > > 3. I think getSystemProxySettings() is a great idea... glad to see it > there. > > 4. I haven't addressed WPAD or autodetect in the above, but I've run > out of time for the moment. > > I realize what I've written is a huge change from what you've already > proposed, Eric. I hope you take this constructively. I have been > dealing with proxy-related browser topics for years now, and if I were > to have my druthers or write my own browser, this is what I would do. > > Best regards, > Eric H. Jung > Author - FoxyProxy > mozdev.org board of directors > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
