From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: 2001010901 Mozilla currently does not fully implement all functions listed in http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html In our case the problem is, our autoproxy relies heavily on shExpMatch function. There is stub definition for this function in nsAutoProxyConfig.js that always returns False. Thus, all internal hosts (that are detected using this function) in our case are skipped, and using autoproxy basically degrades to setting fixed proxy URL. The above mentioned URL mandates this function (shExpMatch), while comments in nsAutoProxyConfig.js say it is obsolete. It may be obsolete, but ignoring this function makes exisitng proxy scripts useless. I've tried to comment out shExpMatch (in hope, there is built in implementation) but it completely stopped autoproxy from working. Reproducible: Always Steps to Reproduce: 1. Copy nsAutoProxyConfig.js in Components 2. Edit it and add something like if ( shExpMatch(host, "host.of.your.liking")) { return "proxy1"; } return "proxy2"; as contents of FindProxyForURL 3. Try to connect. You'll see, that proxy1 will NEVER be used Actual Results: proxy2 was always used Expected Results: In case of "url.of.your.liking" proxy1 should be used

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

vrfy dup

qa to me reopening Set OS+Plat to ALL reduced severity to major made dependent on 58030.

Hmm... this bug opened quit long ago. Does anybody checked shExpMatch on fresh mozilla builds? I believe that current implementation of shExpMatch are likely buggy, but at least it's not stub and not always returns true. :-)

Its present - can someone give an example which doesn't work? (Someone in 53080 mentioned problems with some URLs - see "Additional Comments From Jonathan Baron 2001-05-09 00:32" in that bug) Also, correcting typo in the dependant bug.

An example of what doesn't work is this. Enter as the auomatic proxy configuration URL http://proxy.library.upenn.edu/pennproxy.pac Then go to the URL http://www.library.upenn.edu/facilities/count_use.html?resource=Organizational%20Behavior%20and%20Human%20Decision%20Processes&method=ejs&url=http://www.idealibrary.com/cgi-bin/links/toc/ob and this does not work. But if you just enter the very end of this on the right, namely, http://www.idealibrary.com/cgi-bin/links/toc/ob this works. You get asked for you password, and if you get that far it works. Perhaps the length is a problem. Another example of what does not work is to go to the page http://www.library.upenn.edu/webbin5/resources/dbfast.cgi?general and try Medline. Here the url is just too long to copy. Jon (baron@psych.upenn.edu)

For the classic implementation of shExpMatch/regExpMatch (so you don't need to reverse-engineer), see http://lxr.mozilla.org/classic/source/network/main/mkautocf.c#1552

setting bug status to New

-->PAC bugs to Jussi

As for URL not working for pennpac, it just contains an error. :-) PAC is tested URL against "http://www.library.upenn.edu/facilities/count_use_proxy.html*" pattern (note "count_use_proxy.html" here), but URl itself has only "count_use.html", w/o "_proxy" So, give me another example, please

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

Here is another proxy URL that reproduces this bug. http://webpac.nevada.edu:8080/proxy.pac

basic suggested I provide some URLs the proxy is supposed to invoke in so here you guys are. What should happen is when you go to a library subscription resource the UNLV login screen should take over. http://search.epnet.com/ See http://library.nevada.edu/resources/fulltext.html and click on all the links with telephone icons(indicating remote access allowed) for more testing.

I finally got around to trying this out, and I can't seem to reproduce the problem. Both search.epnet.com and the links marked with the telephone icon trigger PAC results of "PROXY techserve.lv-lib.nevada.edu:8080" as they should. I didn't actually connect to this proxy (as I am inside another firewall, it's impossible), so if there is a non-PAC related connection issue I wouldn't see it. Still looking for a test case which displays bad behavior...

The proxy stuff works for me now. I haden't tried in a while since I was out of school and on vacation, but I decided to take a look and on my current copy of Mozilla (0.9.3+ 2001081008 MacOS) and everything is fine such as accessing a library resource brings up a login screen as it should.

If it's good for all reports, someone who has tested the function can mark it resolved/RFM. Does anyone want to volunteer some kind of standard unit test for this function?

Well, I did some testing and its WFM, but, probably, I cannot be trusted, because I'm author of that new shExpMatch :-)

can we resolve this already?

shExpMatch is implemented, and I couldn't find any obvious problems with it. I was able to use the PAC file at http://libproxy.syr.edu/ which makes repeated use of shExpMatch in a somewhat ham-fisted manner. If someone finds specific bugs in the future please file a new bug for those. This function WORKSFORME.