Post by r***@gmail.comOn Jun 11, 9:50 am, "Volodymyr M. Shcherbyna"
Post by Volodymyr M. ShcherbynaIf you have sources, you can get the default timeout using
InternetGetOption. You can change the timeout using InternetSetOption
function, read thread:http://groups.google.com/group/microsoft.public.inetsdk.programming.w...
--
V.
This posting is provided "AS IS" with no warranties, and confers no
Post by r***@gmail.comOn Jun 8, 4:27 am, "Volodymyr M. Shcherbyna"
Post by Volodymyr M. ShcherbynaYes, updates to newer versions of IE may influence wininet applications. If
you have access to the code, you can see if the application is setting
timeouts, if not - try to set it to reasonable value.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
Post by r***@gmail.comGreetings.
We use a library written in C++ to upload files to a given server.
This library is old (I estimate 10+ years) and I could only find
partial source to it. Judging from the source, it uses wininet.
A few weeks ago, some locations updated to IE7. Our uploads from
those locations stopped. I haven't been able to figure out if that
is
a direct cause, or just a spooky coincidence.
My question is: does the IE7 update cause changes to wininet that
would start causing problems? If needbe, I can sift through the
source for our library and pick out what I think is the problem area.
We've tried a variety of registry settings (outlined below), to no
seeming avail.
Any help is appreciated.
-Ross
in [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion
\Internet Settings]
DnsCacheTimeout (3 minutes)
KeepAliveTimeout (1 minute)
ServerInfoTimeout (2 minutes)
ReceiveTimeout (10 minutes)
SendTimeout (10 minutes)
I don't think the library sets the timeouts at all.
What are the defaults?
I should also point out that I don't think I have all of the original
source. That's why I was floating the question of whether or not you
could use registry settings to manipulate wininet.
I know we could also use native C# classes and upload the files that
way, but I sincerely doubt that we will be able to get the capital and
project request finished before the IE7 patch goes into full
production, let alone some sort of wininet contingency. Which is
mildly problematic. So now, us lowly developers are scrambling for a
way to fix our wininet dependencies without any code changes. Which
also seems mildly problematic.
After a bit more research, I'm reasonably confident that wininet is
being changed, and that the source of our pain is probably the upgrade
to IE7. Supposedly, the "SendTimeout" key I have above is supposed to
alleviate that problem, but it isn't working for me.
Any ideas?
Well, after about a day's worth of digging through old machines and
source code repository backups, I managed to find the original build
file, and subsequently, all of the dependencies I'd need to build that
library. I got totally, extremely, excruciatingly lucky.
That said - what I didn't realize before is that instead of a straight
DLL, the project that is failing uses a COM version of our uploader
library. Which is well and good, except now it requires more than a
simple bait-and-switch scenario: Making the code modifications and a
new COM interop is not the problem - the problem becomes the fact that
I'd have to recompile the C# application to pick up the new interop
library, at least as far as I can tell, and that would require a
project redeployment, putting me right smack-dab in the middle of
square one.
Ergo, me searching for potential answers in the registry versus
answers in code.
Regardless, we'll have to do something when IE7 gets pushed out, it's
more of a matter of what we're going to deploy versus simple registry
changes.
Thanks again,
Ross
Well, as it turns out, while wininet was the root problem, timeouts
had nothing to do with it.
As of version 7 of wininet, Microsoft no longer allows loose coupling
to MIME encodings. I narrowed it down to one wininet function -
HttpOpenRequest - based upon the output in the COM library's log (that
I stumbled across). I had been shown an article stating that
Microsoft had buckled down on how parameters to wininet functions are
handled, so I started with what we pass in. We pass null for the
lplpszAcceptTypes - which as of version 7.0, defaults wininet to
accepting only the MIME encoding of text/* (according to
http://msdn.microsoft.com/en-us/library/aa384233(VS.85).aspx). The
trouble there is we're trying to send compressed zip files. I went
in, added "application/zip" as a MIME type, recompiled, installed it
in QA, and QA uploads seemed to have worked.
The really lucky thing here is that C# does not require a new interop
compilation IF AND ONLY IF your method stubs are all the same.
I have had a lot of good luck on this project, and I'm happy to call
it resolved.
-Ross