296163 - Auto-detect proxy settings (proxy configuration over a URL, PAC) doesn't work if PAC file contains non-ASCII text

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Alexander Kluss]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050518
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050530

The proxy configuration over a URL like http://proxyconf doesn't work.
Sites with access over the proxy could not be reach. 

I found the problem with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050518
and reproduce it with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050530

There are no problems with the release version of Mozilla 1.8b.

Reproducible: Always

Steps to Reproduce:
Use a proxyserver to access sites and use a configuration scrit to setup the
browser.

Comment 1

[Alexander Kluss]

Attachment: Mozilla http-debug protocol

The proxy configuration file was loaded from Mozilla but was not used to set up
the proxy.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

A good way to get closer to the problem is to test nightly builds between this
two beta releases. When does the bug first occur? If we have a date then we
could take a look at the checkins on that day. 

Are the URLs you trying to load in inside your LAN? Do they contain secret
content or can you post the content of the pac file?

Comment 3

[Alexander Kluss]

Do you have any nighly builds between February and Mai? The oldest builds on
ftp.mozilla.org are from middle Mai. I have no builds from this time.

The URL for the PAC is in our LAN but I think I could post a part of the PAC
when I delete the the IPs.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

try http://archive.mozilla.org maybe

Comment 5

[Frank Wein [:mcsmurf]]

BTW: Does it work when you manually press the button "Reload" in the Proxy
configuration dialog?

Comment 6

[Alexander Kluss]

It doesn't work when I press "Reload". I have only a connection to the Internet
when I manually enter the proxyserver and port.

The tests with the older nightlies following in the next week.

Comment 7

[OstGote!]

*** Bug 296445 has been marked as a duplicate of this bug. ***

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mmh while using a pac file for myself at work I can't reproduce this with Deer
Park Alpha 1. I've only the problem that it doesn't work on startup when loading
the homepage. Reloading the page shows it correctly. But this is bug 247057.

Comment 9

[Darin Fisher]

based on the log file, this appears to be a duplicate of bug 100022.  the PAC
file is loaded after the home page is loaded.

*** This bug has been marked as a duplicate of 100022 ***

Comment 10

[Alexander Kluss]

The two bugs (296163 and 100022) are not the same. The auto-detect has always
worked and with the actual version it never work.

Not with the first page, not with the second, no page will be loaded over the
proxy when the proxy settings will be set over a PAC.

You can get also a debug log with 20 retrys of different pages.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

> You can get also a debug log with 20 retrys of different pages.

could you attach that one?

Comment 12

[Alexander Kluss]

> > You can get also a debug log with 20 retrys of different pages.
> could you attach that one?

Thats no problem, I can attach it tomorrow.
How long I must be wait befor I reload the page? Until the timeout?

When I find enouth free time tomorrow I will test different nightly from the
last months to say the first version with this problem. Otherwise I will test it
in the current week.

Comment 13

[Alexander Kluss]

Attachment: a longer http debug log

In this file I made several retrys for two domains. For the last retry I made a
manual reload from the proxy config file.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Btw. do you get any error within the JavaScript Console? Don't forget to
activate strict javascript warnings and there showing.

Comment 15

[Alexander Kluss]

I have activate the JS Warnings and made a restart from Mozilla but I get no
entrys in the JavaScript Console.

Comment 16

[Darin Fisher]

Can you load http://proxyconf/ in a browser window and copy the contents to this
bug report?  That would help us debug the problem.  Thanks!

Comment 17

[Alexander Kluss]

Attachment: this is the PAC.

Comment 18

[Darin Fisher]

It appears that the PAC file contains some non-ASCII text.  The new isAscii
check in nsPACMan.cpp is getting hit, and that is causing the PAC load to fail:
http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsPACMan.cpp#376

Perhaps we should ignore that error, and just proceed to treat the text as
ISO-Latin-1.  That would be consistent with the older versions of the browser.

Comment 19

[Darin Fisher]

The non-ASCII byte 0xCF appears twice in the PAC file, but in both cases it only
appears inside a comment section.  So, treating it as ISO-Latin-1 when
converting to Unicode would not cause any problems for this PAC file.

Comment 20

[Darin Fisher]

Attachment: v1 patch

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 186141 [details] [diff] [review]
v1 patch

people wanting to use IDN or somesuch will just have to use \u1234 escapes, I
guess..

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

(unless, of course, ISO-8859-1 suffices for them)

Comment 23

[Darin Fisher]

Comment on attachment 186141 [details] [diff] [review]
v1 patch

This patch restores our code to the way it was in Gecko versions 1.8b1 and
earlier.

Comment 24

[Darin Fisher]

fixed-on-trunk

Comment 25

[Alexander Kluss]

It works fine. Thanks.

testet with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050621

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug isn't fully fixed. At work we are using the rewrite engine of apache on
the web server. In that case the pac file couldn't be loaded by the first
connection. It seems that only one connection is made to retrieve the pac file
before the start page is loaded? I'll attach my HTTP log. 

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: HTTP log with failed loading of the pac information

Comment 28

[Darin Fisher]

Henrik: I think you are talking about a different bug.  This bug is about a
regression that occured recently involving non-ASCII characters appearing in the
text of the PAC file.  I think there is already a bug on file regarding the
issue you are describing, and I have a patch for that.  See bug 100022.

Marking FIXED (again)

Comment 29

[will mooney]

I'm using TB 1.1a 20050622  and I get a problem with the autoload of proxy info.

The pac file may have non-ascii chars in it? The header looks like this. I 
can't post any more because it has server names

/* DO NOT EDIT! DO NOT EDIT! DO NOT EDIT! DO NOT EDIT!
1,1,-1,-1
1,.aaa.com
 
 
 
 * Proxy autoconfig file for Netscape Navigator
 * Generated by Netscape-Proxy/2.5
 * Generated on Mon Dec 30 18:28:20 1996
 
 *
 * DO NOT EDIT! DO NOT EDIT! DO NOT EDIT! DO NOT EDIT!
 *Any changes you make could be overwritten by the admin interface
 */
function FindProxyForURL(url, host)
{
        // Direct connections to non-aaa hosts
        if (isPlainHostName(host)) {
            return "DIRECT";
        }
 
        // Direct connections to local domain
  


This caused the endless throbber in TB. The JavaScript console reports:

Error: redeclaration of const kMailToLength 
Source File: chrome://communicator/content/nsContextMenu.js 
Line: 13 

Error: redeclaration of const imgICache 
Source File: chrome://communicator/content/contentAreaUtils.js 
Line: 232 

Error: [Exception... "Component returned failure code: 0x80040111 
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult: "0x80040111 
(NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: chrome://messenger-
newsblog/content/Feed.js :: anonymous :: line 174" data: no] 
Source File: chrome://messenger-newsblog/content/Feed.js 
Line: 174 (Twice) 

Is this the same bug?
thanks

Comment 30

[Darin Fisher]

will: please file a new bug, and attach a PAC file that demonstrates the
problem.  if you cannot attach the PAC file from your company, then please
create a reduced version that you can submit to the new bug report that you
file.  thanks!

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #29)
> This caused the endless throbber in TB. The JavaScript console reports:
> 
> Error: redeclaration of const kMailToLength 
> Source File: chrome://communicator/content/nsContextMenu.js 
> Line: 13 
> 
> Error: redeclaration of const imgICache 
> Source File: chrome://communicator/content/contentAreaUtils.js 
> Line: 232 

Will, none of this errors are related to this bug. kMailToLength is already
covered by bug 298624 where I already attached a patch. imgICache will come
tomorrow.