Urgent problem: Cannot connect to URL

[Markus Strobl]

hi,

the browsers of ours customers are configured to retrieve proxy settings via
..pac autoconfiguration file.
if the file referenced by the url specified is out of date, internet
explorer downloads this file and somehow will execute the javascript in it
.....

now lets look on our problem: when sending a http request using wininet.dll
the first request fails with wininet-error 12029 (cannot connect) .. the
client isn't even seen on the proxy server, but every following request
succeeds ... so our guess is, the component has a problem retrieving the
proxy server the first time and uses some kind of default proxy-settings for
the following attemps.

this only happens when starting our program with a normal user, when
starting as an admin-user it succeeds. so perhaps the user has no right to
execute the java script? does anybody know in wich way the javascript in the
..pac file is executed?

if we try to navigate to this url using internet explorer it succeeds every
time, even with the normal user.
so its a very strange thing and we don't have any clue where to start
researching.

we have the problem on certain places using internet explorer 6 and 5.
version number of the wininet.dll is v5.0.29.19.6305 and we're running
windows nt 4.0 SP 6.

please help, because its a very urgent problem to me ...
thanks a lot for any help!!!

greetings markus

 

[Robert Aldwinckle]

the first request fails with wininet-error 12029 (cannot connect)

Do you have a packet trace of the two cases?

Which OS? FWIW I recently discovered that on XP you could use
its netcap tool if you don't have anything better for capturing packets.

does anybody know in which way the javascript in the
.pac file is executed?

Don't know. Is that script affected by the Security settings
for scripting? E.g. do you see a prompt if you change your
settings to Prompt for Active Scripting? (That might let you
know if there is a timing factor involved.)


Good luck

Robert Aldwinckle

 

[Markus Strobl]

hi!

thanks a lot for your reply .. we researched more (incl. network-traces) in
this case and found the following behaviour which in our oppinion is a bug
in wininet.dll (or any dependant library):

our clients are configured to use a .pac file for automatic proxy
configuration. when starting our application which uses wininet.dll for
http-access, the .pac-file isn't used at all although we passed
INTERNET_OPEN_TYPE_PRECONFIG to the InternetOpen-function which should read
the proxy-configuration from the ie-registry-settings.
the function HttpSendRequest from wininet.dll somehow totally ignores the
proxy-settings on the first try and tries to connect directly to the
webserver (without proxy). this wasn't possible from the client we found
this problem because routers with accesslists were between the client and
the webserver!
wininet.dll retried to connect a few times and then failed.
on the second request the .pac file is downloaded from the proxy (as it
should be) and everything worked fine.
internet explorer didn't download the .pac file too but somehow knew he has
to go over the proxy...
this was only the case when we were logged in as a normal user. when we were
logged in as administrator everything worked fine from our application.
we are running windows nt 4.0 sp6 on our clients and apache with webshere on
the server.
what's your oppinion in this case?

greetings markus

 

[Markus Strobl]

so ... i forgot to say how i worked around this problem :

i read the internetexplorer-settings using InternetQueryInfo and if
proxy-autoconfiguration
is checked then i download the .pac file manually, retrieved the proxy to
use by using jsproxy.dll
and then passed the proxy to use to InternetOpen and it worked ...

greetings



"Markus Strobl"

 

[Robert Aldwinckle]

we researched more (incl. network-traces) in this case and found

the following behaviour which in our opinion is a bug in wininet.dll ....
what's your opinion in this case?

You're getting over my head, Markus.

However, your mention of wininet.dll makes me wonder if you should
be trying any of the many hotfixes for that module that are available.

For example, the following MSKB Boolean search finds 19 hits:

wininet AND kbie600presp2fix

Refining that further with

wininet AND kbie600presp2fix AND proxy

reduces them to two:

<TITLE>331906 - You Cannot Connect to the Internet After You Install Microsoft Updates</TITLE>

<TITLE>820780 - Internet Explorer Always Prompts for Authentitication When Browsing to Web Sites Already Logged On To</TITLE>

The latter would bring the module's version up to 6.0.2800.1243


Unfortunately, none of the wininet problems apparently rate as security
problems; otherwise I think we would have seen wininet.dll included
in one of the IE cumulative updates. So you either have to request
a hotfix or wait for the next service pack.


Hang on. SYNCHRONICITY! (Brand new!)

<TITLE>Microsoft Security Bulletin MS04-004</TITLE>
< http://www.microsoft.com/technet/security/bulletin/ms04-004.asp?frame=true >

<quote>
22-Jan-2004 00:16 6.00.2800.1400 588,288 Wininet.dll X86
</quote>


Hmm... I was only looking for IE6sp1 cases. For IE55sp2 cases
there would be this:

<TITLE>314907 - Internet Explorer Prompts for Your User Name and Password Four Times</TITLE>

(MSKB Boolean search for
wininet AND kbie550presp3fix
)

That would bring the module version up to 5.50.4912.1700

In this case for some reason wininet.dll was included with some earlier
security patches. So, IE55sp2 users with the previous critical updates
should already have 5.50.4918.600.

< http://www.microsoft.com/technet/security/bulletin/MS03-048.asp?frame=true >

and now in this newest cumulative update you can get (for WinME?)
version 5.50.4937.800


Well, if I haven't lost you the idea would be to get this latest security
update and thereby get (or hope you get) the equivalent of any hotfixes
you need.


Good luck

Robert

 

[Markus Strobl]

thanks for your effort, robert!

we have already tried the 2 patches you mentioned but it didn't work either
....
so for now we can live with our workaround but i think to completely resolve
this case
i have to dig deeper or as you mentioned hope, ms will correct this
behaviour in a
reasonable period of time ...

best wishes - markus

You're getting over my head, Markus.

However, your mention of wininet.dll makes me wonder if you should
be trying any of the many hotfixes for that module that are available.

For example, the following MSKB Boolean search finds 19 hits:

wininet AND kbie600presp2fix

Refining that further with

wininet AND kbie600presp2fix AND proxy

reduces them to two:

<TITLE>331906 - You Cannot Connect to the Internet After You Install

<TITLE>820780 - Internet Explorer Always Prompts for Authentitication When

The latter would bring the module's version up to 6.0.2800.1243


Unfortunately, none of the wininet problems apparently rate as security
problems; otherwise I think we would have seen wininet.dll included
in one of the IE cumulative updates. So you either have to request
a hotfix or wait for the next service pack.


Hang on. SYNCHRONICITY! (Brand new!)

<TITLE>Microsoft Security Bulletin MS04-004</TITLE>
<

http://www.microsoft.com/technet/security/bulletin/ms04-004.asp?frame=true >

<quote>
22-Jan-2004 00:16 6.00.2800.1400 588,288 Wininet.dll X86
</quote>


Hmm... I was only looking for IE6sp1 cases. For IE55sp2 cases
there would be this:

<TITLE>314907 - Internet Explorer Prompts for Your User Name and Password

(MSKB Boolean search for
wininet AND kbie550presp3fix
)

That would bring the module version up to 5.50.4912.1700

In this case for some reason wininet.dll was included with some earlier
security patches. So, IE55sp2 users with the previous critical updates
should already have 5.50.4918.600.

<

http://www.microsoft.com/technet/security/bulletin/MS03-048.asp?frame=true >