User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Netscape/8.0, Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Netscape/8.0, I have 10.* in System Preferences proxy bypass settings. Safari obeys this entry, but Camino does not. Reproducible: Always Steps to Reproduce: Admittedly I have an odd network setup here so I don't know how you might reproduce this. I've got a 192.168.0.0/24 local network and multiple class C networks attached to it, all under 10.*. Routing between the 192 and 10 networks is handled by a Cisco 4500 series switch with a routing software load. The 192 network is NAT'd to the outside world and has an outbound web proxy. If I enter the 10.* exlusion into System Preferences, Safari can access the web servers on any of the the class C ranges allocated. If I delete the 10.* exclusion, Safari goes to the proxy. In either case Camino goes to the proxy, which is not correct. Actual Results: Camino always goes to the proxy, whether the 10.* exclusion is entered or not. Expected Results: Camino shouldn't go to the proxy for any address under 10.0.0.0/8.
I knew this bug looked familiar: it was bug 185649, closed WFM after the last commentor never replied and after some careful testing from benc. Hmm.
Tim, is this still a problem with Camino 1.5? If it is, and you can provide more information (and perhaps answer some of the questions in bug 185649), please feel free to re-open this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INCOMPLETE
Seems to be still a problem. Specific case below. Note that I'm not using a PAC. -- Here's my exclusion list: 127.0.0.1 localhost 192.168.0.* 10.* 10.0.0.* 10.0.* *.local. -- Here's a local bonjour name & IP (one of my printers): stovetop:~ cerebus$ ping npifc8232.local. PING npifc8232.local (192.168.0.45): 56 data bytes 64 bytes from 192.168.0.45: icmp_seq=0 ttl=64 time=1.838 ms -- With Camino (Version 2007050909 (1.5)): This URL works: http://npifc8232.local./ This URL doesn't work: http://192.168.0.45/ The error page in this case comes from my proxy, so clearly Camino is not obeying the exclusions correctly. Both URLs work in Safari.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
=> NEW This is probably a good case study about the limits or problems of doing something like Camino. As I understand it, Camino is reading the string from the preference. The only problem is that the Necko parsing of this string is significantly different that what Netscape Communicator or IE support. I wrote the following a long time ago, so little bits might be incorrect, but you get the idea: http://www.mozilla.org/quality/networking/docs/aboutno_proxy_for.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
So it sounds like we need to do some transformations on the values that are invalid in necko before we set those exclusions in the pref....
Assignee: mikepinkerton → nobody
QA Contact: os.integration
Yeah. Here's Apples official guide. http://docs.info.apple.com/article.html?artnum=301534. I found the explanation confusing, so I sent them some feedback, but I think we could list the supported formats, and map them into an expression that necko will correctly eumulate.
See also bug 470207, whose code may or may not be helpful here (ours lives in PreferenceManager, it appears).
Based on comment 3 and benc's doc and some simple testing, it sounds like we're doing the right thing for *.foo (Firefox was not; that was one of the things Josh fixed in bug 470207). What we'd need to do is convert trailing-* IP-based exceptions into the proper "IP-Segment/Submask" (so Tim's 192.168.0.* and various 10.* exceptions would need to be changed into whatever the appropriate submasks are for those). We may also want to remove any invalid-per-Necko exceptions, like internal-*-style ones (www.*.net); right now, those get listed but Necko just ignores them. (If bug 314712 is ever fixed, we'd then need to adapt to those changes, i.e. to Necko hostnames are all string-matching, not FQDN-based.) This sounds like only a little bit of string manipulation needed (see the bit about exceptions toward the tail end of PreferenceManager's |readSystemProxySettings|) and someone who knows the submask system.
Summary: Camino not obeying all bypass proxy settings. → Camino not obeying all bypass proxy settings (IPs with trailing * need mapping to submasks)
Whiteboard: [good first bug]
You need to log in before you can comment on or make changes to this bug.