(No comment was entered for this change.)

Context: this is related to  bug  24641  -- basically once we bodge the existing PAC functions to match IE rather 
than Firefox (such that they no longer support IPv6), we should follow up by adding the IPv6 capable extensions.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=30127 

------------------------------------------------------------------------
r30127 | eroman@chromium.org | 2009-10-26 16:51:28 -0700 (Mon, 26 Oct 2009) | 25 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/load_log_event_type_list.h?r1=30127&r2=30126
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/data/proxy_resolver_v8_unittest/bindings.js?r1=30127&r2=30126
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/data/proxy_resolver_v8_unittest/dns_fail.js
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.cc?r1=30127&r2=30126
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.h?r1=30127&r2=30126
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings_unittest.cc?r1=30127&r2=30126
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_script.h?r1=30127&r2=30126
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.cc?r1=30127&r2=30126
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8_unittest.cc?r1=30127&r2=30126

Add three of the six extensions to PAC that Internet Explorer supports. 

The following descriptions were taken from <http://blogs.msdn.com/wndp/articles/IPV6_PAC_Extensions_v0_9.aspx> 

---------------------------- 
* myIpAddressEx(): 
Returns a semi-colon delimited string containing all IP addresses for localhost (IPv6 and/or IPv4), or an empty string if unable to resolve localhost to an IP address. 

* dnsResolveEx(host): 
Returns semi-colon delimited string containing IPv6 and IPv4 addresses or an empty string if host is not resolvable. 

* isResolvableEx(): 
Returns TRUE if the host is resolvable to a IPv4 or IPv6 address, FALSE otherwise. 
---------------------------- 

These differ from the vanilla PAC functions in the following ways: 

* myIpAddressEx() returns all the addrsses for localhost (including IPv6 ones), whereas myIpAddress() only returns the first IPv4 one. 
* On failure, myIpAddress() returns "127.0.0.1" whereas on failure myIpAddressEx() returns empty string. 
* dnsResolveEx() returns a list of addresses (including IPV6 ones), whereas dnsResolve() only returns the first IPv4 address. 
* On failure, dnsResolve() returns |null|, whereas on failure dnsResolveEx() returns empty string. 

BUG=25407
TEST=ProxyResolverV8Test.DNSResolutionFailure, ProxyResolverJSBindingsTest.RestrictAddressFamily, ProxyResolverJSBindingsTest.ExFunctionsReturnList
Review URL: http://codereview.chromium.org/333006
------------------------------------------------------------------------

Ok, I added myIpAddressEx(), dnsResolveEx() and isResolvableEx().

I implemented them as described by <http://blogs.msdn.com/wndp/articles/IPV6_PAC_Extensions_v0_9.aspx>.

Unfortunately, that spec doesn't precisely line up with what Internet Explorer does (in respect to square brackets 
in IPv6 literals). I am following up on that post to ask how those cases are supposed to work.

I'm using google-chrome 4.0.249.30 on a fedora 12 linux box. The issue is that the 
machine has more than one valid IPv4 address, as many linux boxes do. The 
myIpAddress() function returns 'the first' IPv4 address it can find - whichever one 
that is. The function thus incidently returns the IPv4-address of the loopback 
adapter 127.0.0.1 which is bogus of course.

As most problems are caused on laptops travelling between home and office, I thought 
of a workaround: use dnsResolve() to investigate if the proxy-server is accessible 
(return "DIRECT" if not) before any other checks. 

The real problem is to have myIpAddress() to return the IP-address actually being 
used by the browser, not one from a random(?) list.

@martin.dragt: We should have this discussion on a separate issue, since it isn't really 
related to the IE PAC extensions.

I am tempted to say that behavior is "working as intended", since AFAIK that is what 
Firefox and other browsers will do too. myIpAddress() does not try to get the IP of the 
default interface, but rather is equivalent to a dnsResolve(<my computer's host name>). 
(However I think it would be reasonable to skip over 127.0.0.1 if there are other 
addresses.)

One workaround you can do is use the myIPAddressEx() extension to get all of the 
addresses, and then filter out the ones you don't care for (such as ::1, 127.0.0.1):

  var my_addresses = myIpAddressEx().split(";");

  for (var i = 0; i < my_addresses.length; ++i) {
    if (my_addresses[i] == XXXXXXX) {
       ...
    }
  }

Alternately, for your use-case, it sounds like you could just do:

    return "PROXY foobar:80; DIRECT";

Now if the browser can't connect to foobar:80, it will fallback to DIRECT (this is faster than 
testing resolvability from the PAC script, since we cache the failure rather than re-testing 
on each request).

Labels Update:

Replace Area-BrowserBackend by Area-Internals