86856 - PAC: [e-mail]'s file

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Mike Kaply [:mkaply]]

I'm attaching a PAC file.

When using this file on 4.x, when I type www.yahoo.com in the URL bar, 4.x hits 
the proxy server and this is obvious from the messages in the URL bar.

On current Mozilla builds, I don't see the same behavior.

My guess is that shExpMatch doesn't work. Unfortunately I can't use alerts in 
here to debug it. Any other advice on how to debug this?

Thanks

Comment 1

[Mike Kaply [:mkaply]]

Attachment: PAC file that fails

Comment 2

[Chase Tingley]

shExpMatch() is bug 65034, which was filed long ago and is currently looking for
a new testcase.

Also, there's something funny going on with isPlainHostName(); see bug 79502.

Comment 3

[benc]

We don't have have a multi-vote system, so I'm going to make this up as I go.

tingley: I think we should handle the inflow of PAC bugs this way:

1- rename each bug "PAC: <reporter> "'s" file

2- Mark each bug as a blocker to the new meta bug + depends for the bug for each
function that is not working.

(I changed the summary already)

asa: how does that sound?

Comment 4

[Chase Tingley]

Another issue in this PAC:
   return "PROXY 172.20.253.4;DIRECT";

AFAIK this we're still ignoring everything after the first return value; see
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsProxyAutoConfig.js#75 .
http://www.mozilla.org/docs/netlib/pac.html claims there's no bug assigned for
this, but bug 86874 seems good enough.

Comment 5

[Chase Tingley]

Sorry for spam.  You all knew I meant bug 84798.

Comment 6

[Jussi-Pekka Mantere]

Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka

Comment 7

[basic]

Michael: This should be fixed in the latest nightly. Could you test and see if
it still fails?

Comment 8

[Mike Kaply [:mkaply]]

I'll give it a look.

What about 65034 and 84798?

Comment 9

[basic]

65034 might be invalid or worksforme
84798 doesn't affect your PAC as the currently the proxy system automatically do
DIRECT when it fails.

Comment 10

[Chase Tingley]

Removing the dependency on bug 84798 because as basic points out we'll default
to DIRECT anyway.

That leaves shExpMatch(), which no one can seem to prove is actually broken.

I've talked with mkaply, who says he can't exactly reproduce the environment (he
got the PAC file from a customer), but gave me the ok to mark this fixed.

Comment 11

[benc]

REOPEN, qa to me.

Comment 12

[benc]

RESOLVED: WFM (no patch is correlated w/ this working)