Bug in IE8+WinInet: ignores max connections

[belochka]

Hi guys,

It seems like IE8 installation with the new WinInet has a severe bug. Here
is a story.

My application is a download manager (VC++/MFC/WinInet) which downloads a
bunch of files from the deployment servers. I use the ASYNC WinInet functions
to resolve the timeout issues. Plus, the download engine is multithreaded
itself i.e. each thread is responsible for downloading a single file.

When the download thread is started, i execute a regular sequence of WinInet
calls:

InternetOpen
InternetSetStatusCallback // to set the ASYNC status callback for all
subsequent calls
InternetConnect
HttpOpenRequest
HttpSendRequest

After this in the loop i retrieve the portions of bytes using:

InternetReadFileExA(m_hRequest, &m_InetBuff, IRF_ASYNC, (DWORD_PTR)this);

Next, since i want to downlaod files simultaneously, i lauch several
(usually 5) threads. Prior to launching threads i have to override the max
connections setting calling the function:

InternetSetOption(NULL, INTERNET_OPTION_MAX_CONNS_PER_SERVER, &dwVal,
dwSize); // where dwVal == 5

After this, 5 download threads are launched and the download for each file
starts immediately. After any thread finishes, another download thread is
launched so that we always have 5 donwloading thread at a time.

The application worked PERFECTLY during 2 years on tens of thousands of
client computers until IE8 was released for the public!

After IE8 installation, the application is always downloading only 2 files
in parallel while others are waiting for async completion of HttpSendRequest
operation. So, i call InternetSetOption, after that i actually call
InternetQueryOption to make sure that the max conns setting was changed to 5,
then 5 threads are spawned, each executes the sequence of calls above, BUT
only the first 2 start downloading the file, while other 3 are waiting for
HttpSendRequest operation to complete.

This behavior occurs on both Win XP and Vista with IE8.

The problem is for sure caused by IE8 installation, because if i rollback
the system to IE7 or IE6, the issue disappears immediately.

I tried the following things to resolve the issue (nothing helped):

1) Tried to modify registry values (MaxConnectionsPerServer and
MaxConnectionsPer1_0Server) manually per system. Values were modified
successfully, but application behavior did not change.
2) Tried to use shared internet session i.e. calling InternetOpen only once
per application instead of calling it for each downloading thread. Did not
make any difference.

It looks like WinInet 8.0 just ignores the max connections registry settings
and always uses 2 connections at most. This all looks like a serious bug to
me.

Did anyone experience the same behavior after IE8 installation?

Thanks in advance,
Roman.

[Paul Baker [MVP, Windows Desktop Experience]]

This was reported in a beta newsgroup over a year ago:
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=fc01dc7f-65d7-47fd-ab14-6ee9fc52f66a&dg=microsoft.public.internetexplorer.beta

Unfortuntely, I see no response.

What it is doing is what it should be doing according to RFC 2616 section
8.1.4, so it may be a purposeful change that is not yet documented:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

WinInet is commonly used for client to server, whereas WinHTTP is commonly
used for server to server so has no such restriction.

Paul

"belochka" <belo...@discussions.microsoft.com> wrote in message
news:5C6C6D2F-28D6-4D9D...@microsoft.com...

[belochka]

Yes, that one was also reported by me for RC1, before the final release. I
was hoping the released version will solve that problem, but it did not :(((

My download manager is implemented as standalone win32 MFC app as well as
the ActiveX component running on the IE page. Both are having the same
problem after IE8 installation. I also wrote a Java Applet component doing
the same download job for Mac OS and Win32 based on
java.net.HttpURLConnection and java.net.URL. Functionality of this one was
not affected by new IE, because i guess the underlying implementation of
HttpUrlConnection is based on Winsock rather than WinInet.

RFC 2616 section 8.1.4 explains just the default behavior which we were
always able to override. If there is some undocumented new feature of
WinInet 8, the it can be potentially very dangerous to the similar
applications that exist.

If someone else has the same problem, please post here so that i know i'm
not the only one having this issue :)

[Paul Baker [MVP, Windows Desktop Experience]]

Did you get some sort of tracking ID when you reported this in RC1? If so,
you could follow up with it. Did your report make it to Microsoft engineers?

Paul

"belochka" <belo...@discussions.microsoft.com> wrote in message

news:6AD3FDD2-854D-4ED6...@microsoft.com...

[belochka]

Hmm ... may be i missed something, but i dont remember that i was provided
with any tracking ID. Also i did not get any feedback for my reports yet.

I initially wanted to post my question in the IE8 feedback, but did not
have enough rights to post there. May be someone can re-post my question to
the feedback and give me a link so that i can watch it?

[Paul Baker [MVP, Windows Desktop Experience]]

This does not seem to me to be the kind of bug that would creep in
accidentally. It seems more likely that it was an intentional crack down on
standards, though I agree that the wording in the RFC is SHOULD and previous
versions implemented a reasonable way to override the behaviour. Given that
it was likely intentional, it would not have failed testing and there would
have had to have been feedback to Microsoft on how serious the compatibility
problem is for certain applications in order for them to consider changing
it back. It seems what you reported to the beta newsgroup did not get
through and I think that what you are doing is unusual enough that this may
not have bene reported by anyone else (search for
INTERNET_OPTION_MAX_CONNS_PER_SERVER on the Internet and you won't find much
of interest).

Did you report it anywhere else or in any other way?

I think your best hope is to get this reported in a trackable way. I would
expect Microsoft to be able to respond that either they will fix it or to
provide an explanation as to why the behaviour is intentional. However, I am
not sure what the best way to report it to the right people is. I will ask a
contact at Microsoft and get back to you.

Even if it is fixed, there will be unpatched browers out there you must
consider.

Paul

"belochka" <belo...@discussions.microsoft.com> wrote in message

news:8A69CB09-5B0B-486A...@microsoft.com...

[Sheng Jiang[MVP]]

try https://connect.microsoft.com/WNDP/Feedback
it is the feedback web site for Winsock, WSK, QoS, System.NET, WinINet, HTTP
Server API, WinHTTP and the Web Services API

"Paul Baker [MVP, Windows Desktop Experience]"
<paulrich...@community.nospam> wrote in message
news:u1sim0fw...@TK2MSFTNGP02.phx.gbl...

[belochka]

Thanks for the suggestion.

Re-posted my feedback here:

https://connect.microsoft.com/WNDP/feedback/ViewFeedback.aspx?FeedbackID=434396

"Sheng Jiang[MVP]" wrote:
..........

[belochka]

According to http://support.microsoft.com/kb/320721 this is the normal
practice to programmatically override this setting.

I also seems strange enough for me that nobody else reported this issue yet.
May be because IE8 is not so widely spread yet, may be because i'm doing
something wrong in this specific application.

Anyway, i'm going to follow the Sheng Jiang's suggestion and re-post my
message in WinInet feedback. Will see is the can clarify anything.

Thanks for your help.

[Jeff]

The feedback was answered:
https://connect.microsoft.com/WNDP/feedback/ViewFeedback.aspx?FeedbackID=434396

You should get back to them with the repro, or open a support incident with
Developer support (if it is a bug there is no charge for the incident).

[DanielR]

Hi Belocka,

I experienced the same issue and found the solution at

http://msdn.microsoft.com/en-us/library/cc304129(VS.85).aspx

You can add your application name (exe) under the local_machine or
(current_user, I prefer this one) hive, to increase the maximum connections
per server that your application will need.

Regards

Daniel