On Mon, Oct 27, 2008 at 1:15 PM, Avi Drissman <[EMAIL PROTECTED]> wrote:
> The problem isn't PAC parsing, anyway. The Mac proxy code has a call to > handle that. And there are some clever ways to handle the asynchrony, so I > can deal with that too. > > I'm just looking at the mismatch between Mac proxy handling and Windows > proxy handling. Some immediate notes: > > - ProxyConfig.auto_detect is WPAD. There's no concept of this on the Mac; I > suppose we want to default to false here. WPAD just means use http://wpad/wpad.dat as the PAC URL. This is supported by Firefox on all platforms, and it is easy to support in Chrome ;-) > > > - ProxyConfig.proxy_bypass is a comma-delimited list of hosts to bypass. On > the Mac, proxy configuration allows entering entire blocks in CIDR style > (e.g. http://www.tcd.ie/iss/internet/osx_proxy.php); I think we need to > adapt our code to handle this. > Interesting. Mozilla supports that syntax as well. Is the expectation that hostnames will be resolved prior to consulting that list? (That would be unfortunate since proxy servers otherwise avoid client side host name lookup.) -Darin > > This looks like a pain, but a minor one. It shouldn't be too bad adapting > the CFProxy calls to return results similar to the Windows ones. > > a > > On Fri, Oct 24, 2008 at 6:11 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: > >> I have a cross-platform (based on V8) proxy resolver implementation in my >> tree. I just haven't found the time to finish it. We should probably use >> it. >> Then, we'll just need to write code to figure out what the proxy >> configuration is for each operating system. >> >> I plan to change things so that the resolver works asynchronously because >> that will work better for the V8-based resolver (as it needs to download a >> PAC file potentially). >> >> -Darin >> >> >> On Fri, Oct 24, 2008 at 12:22 PM, Avi Drissman <[EMAIL PROTECTED]> wrote: >> >>> Proxy support was thrown my way, and I've been looking at our >>> proxy_service and Apple's CFProxySupport. >>> >>> In 10.4, you could call SCDynamicStoreCopyProxies to get proxy info: a >>> list of exceptions, and proxy addresses. That was it. If you wanted to >>> evaluate PAC files, or parse the exception list, it was your problem. >>> >>> In 10.5, we gained an entire API for dealing with it. You can ask for >>> proxies for a URL, and you can have it parse PAC files, etc. (See >>> http://developer.apple.com/samplecode/CFProxySupportTool/listing2.html.) >>> >>> I was looking at our proxy_service, and it relies on platform-specific >>> proxy_resolvers. Its attempt at cross-platformity is nice but AFAICT not >>> sufficient. Some notes: >>> >>> - It was Win32-isms in it (see line 290 for the special format that the >>> proxy list is supposed to take, WPAC, etc) >>> - It doesn't handle asynchronicity. In Windows, WinHttpGetProxyForUrl is >>> synchronous, so proxy_service spawns a thread to handle the callback. On the >>> Mac, CFNetworkExecuteProxyAutoConfigurationURL is a fully async call that >>> will call back when the PAC is run. >>> >>> If we're trying to behave as Safari and the native proxy handling does on >>> the Mac (which I believe we are) then we should be using the proxy APIs >>> provided by CFNetwork. If so, though, I need to replace all of proxy_service >>> rather than just the _resolver, as the Mac version handles a lot more and >>> I'd have to do a lot of surgery on the _service to allow both async and >>> non-async _resolvers (for whatever the platform requests). >>> >>> Thoughts? >>> >>> Avi >>> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
