User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Due to bugs like <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=48718">48718 </A> and <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=80918">80918</A>, the user sees different proxy usage behavior between Internet Explorer and Chimera. For a user to stop an entire domain from using a proxy in both, they must enter both "domain.com" and "*.domain.com" to achieve the same effect in both. If settings are not duplicated, one of the browsers uses a proxy while the other one dosen't for internal.site.domain.com. Another issue is that the System Preference window will strip off stray dots. Thus if a user attempts to enter the proper method of .domain.com, it changes to simply domain.com. Reproducible: Always Steps to Reproduce:

I've looked for documentation on how Apple thinks this data should be handled, does anyone know where it is? In general, our trunk code treates this as a set of strings to do string compares, which is not the ideal logic. What we have needed (and these bugs describe) is more robust, tokenizing logic, that treats IPv4 addresses as 32bit mask-able numbers and dns fqdns's as parsed hierarchical paths.

Will some simple mapping, like: *.foo.bar -> .foo.bar work most of the time? I guess we might have to drop foo.*.bar.

I never looked at a case where "www.*.com" was used. It sounds like apple wants just pqdn's, and we might need to translate them into a string that will behave w/ our not-so great noproxy feature.

I started to use the OS settings on the test Mac @mozilla.org. If this affects camino seriously, I'd be willing to try to spend more time on this problem.

Simon: can you find out what Apple is doing here? I've looked on their support and dev site, but can't find an explaination for what is going on. Can you provide specific cases where this works wrong? The no proxy code's major bug is that domains are matched as literal strings, not properly treated as domain names. So in mozilla: .mozilla.org and *.mozilla.org both block "all hosts in .mozilla.org." because we do a string match, this does not include the domain "mozilla.org" If you use "mozilla.org", you would block everything, but also false-positive block "supermozilla.org" and any domains which "mozilla.org" is a string suffix.

Simon: I finally started playing w/ the Safari implementation today. I can't find any info from Apple about how this works. The domain problem that Tom describes is fixable, I'll be filing a bug that describes a 1 line change that will make that work correctly in Core/Networking. Assuming we fix that, mapping OS settings to Camino should work better. I don't know if IE-style "*" are supported anywhere in the domain strings. I also don't know if Mac OS thinks about supporting IP address, and if so, in what formats. As for the dot-stripping behavior, I don't see that as of 10.3.7.

Using the 8/16/2005 build, I am still having issues with this. Say my company is "company" and our domain is "company.com". We need all external traffic to go through a proxy but all internal traffic to go direct. So for example, "application.company.com" should go direct, as well as "test.company.com". In my bypass proxy settings, I set "company.com" and Safari correctly goes directly to them while using the proxy for all other sites. I have also tried "*.company.com" with the same results. I want to use Camino, but I just can't until the proxy support is fixed. This and bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=231736">231736</a> just completely make Camino unusable for me since I have to work in at least three different corporate networks, using various VPNs and such - and then my personal use at home... Arrgh. :)

I just tried this: I set my http proxy host to localhost:80 (which won't work because I don't have a proxy server set up), and I entered "apple.com" in the bypass field. It worked as expected; the only site I could visit was apple.com. I was also able to enter two bypass domains ("apple.com, mozilla.org") and got the expected results there too. So, other than the PAC issue, what is the real bug here?

Marking WFM. Please reopen if you have a specific failure case.

Oakland: I've also done some unit testing, and it seems to work for me in 2005091409 (v1.0a1). Are you saying that you are using a PAC file -AND- bypass, and it doesn't work? We treat these as two separate modes (PAC -OR- manual <bypass is part of manual> I don't think anyone has thought about the combination of the two, although a couple vaguely filed IE-does-this-bugs in Mozilla hinted at this.