HttpSendRequest timeout recovery in ocx

[mike]

Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

Once you get error in HttpSendError, just close request handle and try again to open a new request. If it does not help, reconnect. Should work.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[mike]

Well... as I stated, it doesn't and that is why I am posting.

<< all the connection handles and reestablish all new ones

But thank you
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
Once you get error in HttpSendError, just close request handle and try again to open a new request. If it does not help, reconnect. Should work.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

In this case I am not sure, this is a client side problem.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Well... as I stated, it doesn't and that is why I am posting.

<< all the connection handles and reestablish all new ones

But thank you
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
Once you get error in HttpSendError, just close request handle and try again to open a new request. If it does not help, reconnect. Should work.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[mike]

I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Paul Baker [MVP, Windows - SDK]]

With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[mike]

I realized that to be the case when the transmissions dropped off the Fiddler tool's radar and I needed to fireup WireShark.

- Mike
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[mike]

Does WinHTTP use IE's Proxy settigs?
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[mike]

I have found that WinHTTP does not use IE's proxy settings automatically, but there is integration support.

Along with the winhttp.dll comes the proxycfg utility in system32 that, from the command line will import IE's (WinInet's) proxy configuration.

With Vista, the import is accomplished by way of the netsh (shell).

This also gets Fiddler's proxy imported for a debug session.

This is a great relief for me, because as we moved from MS ITC (Internet Transfer Control) to an API that is allows us to be thread safe, and because of the issue that is the subject in this thread, we had no choice but to leapfrog WinInet and go straight to WinHTTP.

We are fortunate in that we do supply our customers with an MSI for loading our ocx files and are able to perform the proxy import during setup. Or at least that's our current plan. Unless anyone has another approach for triggering the import.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Does WinHTTP use IE's Proxy settigs?

[mike]

Oops, I guess it is time to hop over to the WinHTTP forum.

Regards, - Mike
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I have found that WinHTTP does not use IE's proxy settings automatically, but there is integration support.

Along with the winhttp.dll comes the proxycfg utility in system32 that, from the command line will import IE's (WinInet's) proxy configuration.

With Vista, the import is accomplished by way of the netsh (shell).

This also gets Fiddler's proxy imported for a debug session.

This is a great relief for me, because as we moved from MS ITC (Internet Transfer Control) to an API that is allows us to be thread safe, and because of the issue that is the subject in this thread, we had no choice but to leapfrog WinInet and go straight to WinHTTP.

We are fortunate in that we do supply our customers with an MSI for loading our ocx files and are able to perform the proxy import during setup. Or at least that's our current plan. Unless anyone has another approach for triggering the import.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Does WinHTTP use IE's Proxy settigs?

[Paul Baker [MVP, Windows - SDK]]

Haha... yes, I think so, Mike. Syonara from the WinInet folks.

Paul
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
Oops, I guess it is time to hop over to the WinHTTP forum.

Regards, - Mike
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I have found that WinHTTP does not use IE's proxy settings automatically, but there is integration support.

Along with the winhttp.dll comes the proxycfg utility in system32 that, from the command line will import IE's (WinInet's) proxy configuration.

With Vista, the import is accomplished by way of the netsh (shell).

This also gets Fiddler's proxy imported for a debug session.

This is a great relief for me, because as we moved from MS ITC (Internet Transfer Control) to an API that is allows us to be thread safe, and because of the issue that is the subject in this thread, we had no choice but to leapfrog WinInet and go straight to WinHTTP.

We are fortunate in that we do supply our customers with an MSI for loading our ocx files and are able to perform the proxy import during setup. Or at least that's our current plan. Unless anyone has another approach for triggering the import.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Does WinHTTP use IE's Proxy settigs?

[Volodymyr M. Shcherbyna]

Not exactly, WinHTTP seems to be an child of WinInet sources :) Read my answer to your question in this thread.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Haha... yes, I think so, Mike. Syonara from the WinInet folks.

Paul
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
Oops, I guess it is time to hop over to the WinHTTP forum.

Regards, - Mike
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I have found that WinHTTP does not use IE's proxy settings automatically, but there is integration support.

Along with the winhttp.dll comes the proxycfg utility in system32 that, from the command line will import IE's (WinInet's) proxy configuration.

With Vista, the import is accomplished by way of the netsh (shell).

This also gets Fiddler's proxy imported for a debug session.

This is a great relief for me, because as we moved from MS ITC (Internet Transfer Control) to an API that is allows us to be thread safe, and because of the issue that is the subject in this thread, we had no choice but to leapfrog WinInet and go straight to WinHTTP.

We are fortunate in that we do supply our customers with an MSI for loading our ocx files and are able to perform the proxy import during setup. Or at least that's our current plan. Unless anyone has another approach for triggering the import.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Does WinHTTP use IE's Proxy settigs?

[Paul Baker [MVP, Windows - SDK]]

Perhaps, but you only talked about naming, not functionality.

Since there is a WinHTTP newsgroup, I would think that is the best place to ask about it.

Paul :)
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
Not exactly, WinHTTP seems to be an child of WinInet sources :) Read my answer to your question in this thread.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Haha... yes, I think so, Mike. Syonara from the WinInet folks.

Paul
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
Oops, I guess it is time to hop over to the WinHTTP forum.

Regards, - Mike
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I have found that WinHTTP does not use IE's proxy settings automatically, but there is integration support.

Along with the winhttp.dll comes the proxycfg utility in system32 that, from the command line will import IE's (WinInet's) proxy configuration.

With Vista, the import is accomplished by way of the netsh (shell).

This also gets Fiddler's proxy imported for a debug session.

This is a great relief for me, because as we moved from MS ITC (Internet Transfer Control) to an API that is allows us to be thread safe, and because of the issue that is the subject in this thread, we had no choice but to leapfrog WinInet and go straight to WinHTTP.

We are fortunate in that we do supply our customers with an MSI for loading our ocx files and are able to perform the proxy import during setup. Or at least that's our current plan. Unless anyone has another approach for triggering the import.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Does WinHTTP use IE's Proxy settigs?

[Volodymyr M. Shcherbyna]

I was talking about functionality as well. I can prove this by commenting disassembly of both winhttp and wininet dlls.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
Perhaps, but you only talked about naming, not functionality.

Since there is a WinHTTP newsgroup, I would think that is the best place to ask about it.

Paul :)
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
Not exactly, WinHTTP seems to be an child of WinInet sources :) Read my answer to your question in this thread.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Haha... yes, I think so, Mike. Syonara from the WinInet folks.

Paul
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
Oops, I guess it is time to hop over to the WinHTTP forum.

Regards, - Mike
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I have found that WinHTTP does not use IE's proxy settings automatically, but there is integration support.

Along with the winhttp.dll comes the proxycfg utility in system32 that, from the command line will import IE's (WinInet's) proxy configuration.

With Vista, the import is accomplished by way of the netsh (shell).

This also gets Fiddler's proxy imported for a debug session.

This is a great relief for me, because as we moved from MS ITC (Internet Transfer Control) to an API that is allows us to be thread safe, and because of the issue that is the subject in this thread, we had no choice but to leapfrog WinInet and go straight to WinHTTP.

We are fortunate in that we do supply our customers with an MSI for loading our ocx files and are able to perform the proxy import during setup. Or at least that's our current plan. Unless anyone has another approach for triggering the import.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Does WinHTTP use IE's Proxy settigs?

[Volodymyr M. Shcherbyna]

Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Paul Baker [MVP, Windows - SDK]]

Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that bypassing or adjusting some client type stuff like (off the top of my head) authentication, cookies, HTTP redirection (especially to FTP), connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling "real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

I take my words back. WinHTTP does not delegate into WinInet functions, I was confused by the internal names of WinHTTP functions, they are WinInet like. I look at imports of winhttp.dll, and found my mistake: no imports from wininet.dll. Sorry.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that bypassing or adjusting some client type stuff like (off the top of my head) authentication, cookies, HTTP redirection (especially to FTP), connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling "real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Paul Baker [MVP, Windows - SDK]]

Hmmm.

I see a lot of similarly named functions in the source code, it's tricky to see which one is the exported one and what you're really looking at.

So.. for those who are reading... WinHTTP does not use WinInet. Right??

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
I take my words back. WinHTTP does not delegate into WinInet functions, I was confused by the internal names of WinHTTP functions, they are WinInet like. I look at imports of winhttp.dll, and found my mistake: no imports from wininet.dll. Sorry.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that bypassing or adjusting some client type stuff like (off the top of my head) authentication, cookies, HTTP redirection (especially to FTP), connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling "real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

I did more research.

1. WinHttpOpen maps into WinInet function InternetOpenA - there is no dependency to wininet.dll, probably, because of project settings, the function is "included" into winhttp.dll. I can tell for sure, because I see in disassembly of winhttp.dll that the code is originally the wininet version.

2. WinHttpQueryOption maps internally into ***@16 :

.text:4D4FEB89 push eax ; lpBuffer
.text:4D4FEB8A push 26h ; dwOption
.text:4D4FEB8C push [ebp+hInternet] ; hInternet
.text:4D4FEB92 call ***@16 ; InternetQueryOptionA(x,x,x,x)
.text:4D4FEB97 mov [ebp+var_424], eax
.text:4D4FEB9D test eax, eax

Which is an absolute equivalent to wininet version.

3. WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA.
The function is an included but original version of WinInet InternetConnectA:

.text:4D4F98F6 push ebx ; lpszUserName
.text:4D4F98F7 push dword ptr [ebp+nServerPort] ; nServerPort
.text:4D4F98FA push [ebp+lpszServerName] ; lpszServerName
.text:4D4F98FD push [ebp+hInternet] ; hInternet
.text:4D4F9900 call ***@20 ; InternetConnectA(x,x,x,x,x)
.text:4D4F9905 mov edi, eax

And so on. So, the short answer: wininet and winhttp has the common core functions sets. However, WinHTTP includes the Wininet functions without referencing wininet.dll in it's import table.

Paul, you can check this by checking the implementation of "internal" wininet functions which are called by WinHTTP wrappers: they are the same as wininet equivalents.I suppose, this was done in order to save time to develop WinHTTP from scratch.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Hmmm.

I see a lot of similarly named functions in the source code, it's tricky to see which one is the exported one and what you're really looking at.

So.. for those who are reading... WinHTTP does not use WinInet. Right??

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
I take my words back. WinHTTP does not delegate into WinInet functions, I was confused by the internal names of WinHTTP functions, they are WinInet like. I look at imports of winhttp.dll, and found my mistake: no imports from wininet.dll. Sorry.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that bypassing or adjusting some client type stuff like (off the top of my head) authentication, cookies, HTTP redirection (especially to FTP), connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling "real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Paul Baker [MVP, Windows - SDK]]

Oooh. This is what you want me to read. Okay, I have to do some research myself. Thanks,

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I did more research.

1. WinHttpOpen maps into WinInet function InternetOpenA - there is no dependency to wininet.dll, probably, because of project settings, the function is "included" into winhttp.dll. I can tell for sure, because I see in disassembly of winhttp.dll that the code is originally the wininet version.

2. WinHttpQueryOption maps internally into ***@16 :

.text:4D4FEB89 push eax ; lpBuffer
.text:4D4FEB8A push 26h ; dwOption
.text:4D4FEB8C push [ebp+hInternet] ; hInternet
.text:4D4FEB92 call ***@16 ; InternetQueryOptionA(x,x,x,x)
.text:4D4FEB97 mov [ebp+var_424], eax
.text:4D4FEB9D test eax, eax

Which is an absolute equivalent to wininet version.

3. WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA.
The function is an included but original version of WinInet InternetConnectA:

.text:4D4F98F6 push ebx ; lpszUserName
.text:4D4F98F7 push dword ptr [ebp+nServerPort] ; nServerPort
.text:4D4F98FA push [ebp+lpszServerName] ; lpszServerName
.text:4D4F98FD push [ebp+hInternet] ; hInternet
.text:4D4F9900 call ***@20 ; InternetConnectA(x,x,x,x,x)
.text:4D4F9905 mov edi, eax

And so on. So, the short answer: wininet and winhttp has the common core functions sets. However, WinHTTP includes the Wininet functions without referencing wininet.dll in it's import table.

Paul, you can check this by checking the implementation of "internal" wininet functions which are called by WinHTTP wrappers: they are the same as wininet equivalents.I suppose, this was done in order to save time to develop WinHTTP from scratch.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Hmmm.

I see a lot of similarly named functions in the source code, it's tricky to see which one is the exported one and what you're really looking at.

So.. for those who are reading... WinHTTP does not use WinInet. Right??

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
I take my words back. WinHTTP does not delegate into WinInet functions, I was confused by the internal names of WinHTTP functions, they are WinInet like. I look at imports of winhttp.dll, and found my mistake: no imports from wininet.dll. Sorry.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that bypassing or adjusting some client type stuff like (off the top of my head) authentication, cookies, HTTP redirection (especially to FTP), connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling "real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

Don't hesitate to weakup this topic again. MSFT made an real puzzle :)
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:OuR32%***@TK2MSFTNGP05.phx.gbl...
Oooh. This is what you want me to read. Okay, I have to do some research myself. Thanks,

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I did more research.

1. WinHttpOpen maps into WinInet function InternetOpenA - there is no dependency to wininet.dll, probably, because of project settings, the function is "included" into winhttp.dll. I can tell for sure, because I see in disassembly of winhttp.dll that the code is originally the wininet version.

2. WinHttpQueryOption maps internally into ***@16 :

.text:4D4FEB89 push eax ; lpBuffer
.text:4D4FEB8A push 26h ; dwOption
.text:4D4FEB8C push [ebp+hInternet] ; hInternet
.text:4D4FEB92 call ***@16 ; InternetQueryOptionA(x,x,x,x)
.text:4D4FEB97 mov [ebp+var_424], eax
.text:4D4FEB9D test eax, eax

Which is an absolute equivalent to wininet version.

3. WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA.
The function is an included but original version of WinInet InternetConnectA:

.text:4D4F98F6 push ebx ; lpszUserName
.text:4D4F98F7 push dword ptr [ebp+nServerPort] ; nServerPort
.text:4D4F98FA push [ebp+lpszServerName] ; lpszServerName
.text:4D4F98FD push [ebp+hInternet] ; hInternet
.text:4D4F9900 call ***@20 ; InternetConnectA(x,x,x,x,x)
.text:4D4F9905 mov edi, eax

And so on. So, the short answer: wininet and winhttp has the common core functions sets. However, WinHTTP includes the Wininet functions without referencing wininet.dll in it's import table.

Paul, you can check this by checking the implementation of "internal" wininet functions which are called by WinHTTP wrappers: they are the same as wininet equivalents.I suppose, this was done in order to save time to develop WinHTTP from scratch.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Hmmm.

I see a lot of similarly named functions in the source code, it's tricky to see which one is the exported one and what you're really looking at.

So.. for those who are reading... WinHTTP does not use WinInet. Right??

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
I take my words back. WinHTTP does not delegate into WinInet functions, I was confused by the internal names of WinHTTP functions, they are WinInet like. I look at imports of winhttp.dll, and found my mistake: no imports from wininet.dll. Sorry.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that bypassing or adjusting some client type stuff like (off the top of my head) authentication, cookies, HTTP redirection (especially to FTP), connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling "real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and delegates call to HttpWrapSendRequest, which, internally calls quite a big amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is billed as a server-side HTTP implementation to replace the client-oriented WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx additionally makes its (blocking) HttpOpenRequest to "GET" some additional data for the UI, the HttpSendRequest is sometimes failing with "operation timed out."

I've not been able to recover from this while in the ocx's current thread.

That is to say after timing out, I've tried to gracefully break down all the connection handles and reestablish all new ones but still end up timing out on HttpSendRequest. I have tried the sample code from earlier versions of IE that makes a new thread, to no avail. And have tried a Sleep() to perhaps let the web page get some of it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Volodymyr M. Shcherbyna]

I guess, I know why WinHTTP does import WinInet functions directly.

Imagine an application which is sending http requests over Wininet AND
WinHTTP. Assume, that WinHTTP.dll imports functions of WinInet.dll. In this
case, the global wininet data (variables) will be common, because both
wininet.dll and winhttp.dll are loaded into the same process, and they share
the same address space. It means, that theoretically, an application will be
able to set-up request using WinInet functions (InternetOpen,
InternetConnect, HttpOpenRequest, HttpSendRequest) but process it using
WinHTTP functions (calling WinHTTPReadData with handle returned from WinInet
HttpOpenRequest). This behaviour will be incorrect wrong, and confusing.
This probably one of the reasons they decided to separate things.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP03.phx.gbl...
Don't hesitate to weakup this topic again. MSFT made an real puzzle :)
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]" <***@community.nospam>
wrote in message news:OuR32%***@TK2MSFTNGP05.phx.gbl...
Oooh. This is what you want me to read. Okay, I have to do some research
myself. Thanks,

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in message news:***@TK2MSFTNGP05.phx.gbl...
I did more research.

1. WinHttpOpen maps into WinInet function InternetOpenA - there is no
dependency to wininet.dll, probably, because of project settings, the
function is "included" into winhttp.dll. I can tell for sure, because I see
in disassembly of winhttp.dll that the code is originally the wininet
version.

2. WinHttpQueryOption maps internally into ***@16 :

.text:4D4FEB89 push eax ; lpBuffer
.text:4D4FEB8A push 26h ; dwOption
.text:4D4FEB8C push [ebp+hInternet] ; hInternet
.text:4D4FEB92 call ***@16 ;
InternetQueryOptionA(x,x,x,x)
.text:4D4FEB97 mov [ebp+var_424], eax
.text:4D4FEB9D test eax, eax

Which is an absolute equivalent to wininet version.

3. WinHttpConnect - converts paramters from unicode to ansi and
delegates the call to InternetConnectA.
The function is an included but original version of WinInet
InternetConnectA:

.text:4D4F98F6 push ebx ; lpszUserName
.text:4D4F98F7 push dword ptr [ebp+nServerPort] ;
nServerPort
.text:4D4F98FA push [ebp+lpszServerName] ;
lpszServerName
.text:4D4F98FD push [ebp+hInternet] ; hInternet
.text:4D4F9900 call ***@20 ;
InternetConnectA(x,x,x,x,x)
.text:4D4F9905 mov edi, eax

And so on. So, the short answer: wininet and winhttp has the common core
functions sets. However, WinHTTP includes the Wininet functions without
referencing wininet.dll in it's import table.

Paul, you can check this by checking the implementation of "internal"
wininet functions which are called by WinHTTP wrappers: they are the same as
wininet equivalents.I suppose, this was done in order to save time to
develop WinHTTP from scratch.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]"
<***@community.nospam> wrote in message news:***@TK2MSFTNGP06.phx.gbl...
Hmmm.

I see a lot of similarly named functions in the source code, it's
tricky to see which one is the exported one and what you're really looking
at.

So.. for those who are reading... WinHTTP does not use WinInet.
Right??

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in
message news:***@TK2MSFTNGP04.phx.gbl...
I take my words back. WinHTTP does not delegate into WinInet
functions, I was confused by the internal names of WinHTTP functions, they
are WinInet like. I look at imports of winhttp.dll, and found my mistake: no
imports from wininet.dll. Sorry.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]"
<***@community.nospam> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Volodymyr,

Oh really? I am disillusioned now. Sorry for doubting you. This
really should be clearer in the documentation.

Is it calling internal variations of WinInet requests that
bypassing or adjusting some client type stuff like (off the top of my head)
authentication, cookies, HTTP redirection (especially to FTP), connection
limit, MIMe type handling, dialogs and UI stuff, etc.? Or just calling
"real" WinInet?

Even in Vista?

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org> wrote in
message news:***@TK2MSFTNGP05.phx.gbl...
Hello Paul,

Use your MVP benefit, and access codepremium center. Take a look
at the implementation of the following functions,

a) WinHttpOpen - converts parameters from ansi to unicode and
delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to
unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and
delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi
and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and
delegates call to HttpWrapSendRequest, which, internally calls quite a big
amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle

This list may be continued.

--
V.
This posting is provided "AS IS" with no warranties, and confers
no
rights.
"Paul Baker [MVP, Windows - SDK]"
<***@community.nospam> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
With all due respect, I don't think that is true. WinHTTP is
billed as a server-side HTTP implementation to replace the client-oriented
WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx

Paul
"Volodymyr M. Shcherbyna" <***@online.mvps.org>
wrote in message news:***@TK2MSFTNGP02.phx.gbl...
FYI: WinHTTP is based on WinInet. Quite a big amount of
WinHTTP code simply delegates execution into WinInet equivalented functions.

--
V.
This posting is provided "AS IS" with no warranties, and
confers no
rights.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP02.phx.gbl...
I ported toWinHTTP and am no longer able to replicate the
problem.

It was very easy and works very well, I like it.
"mike" <***@m.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
Hello,

I am having trouble with an intermittent error. We're
using WinInet in an ocx on a web page.

When the rather busy web page is building and the ocx
additionally makes its (blocking) HttpOpenRequest to "GET" some additional
data for the UI, the HttpSendRequest is sometimes failing with "operation
timed out."

I've not been able to recover from this while in the
ocx's current thread.

That is to say after timing out, I've tried to
gracefully break down all the connection handles and reestablish all new
ones but still end up timing out on HttpSendRequest. I have tried the sample
code from earlier versions of IE that makes a new thread, to no avail. And
have tried a Sleep() to perhaps let the web page get some of it's work out
of the way.
Iv'e looked at it the traffic and nothing eminates from
the client on the HttpSendRequest.

Nothing seems to work, if it timesout once, that is it?

Any info would surely be appreciated, Thnx

- Mike

[Paul Baker [MVP, Windows - SDK]]

That makes sense.

It also warns against using WinHTTP HINTERNET handles in WinInet in the
documentation.

Paul

Post by Volodymyr M. Shcherbyna
I guess, I know why WinHTTP does import WinInet functions directly.
Imagine an application which is sending http requests over Wininet AND
WinHTTP. Assume, that WinHTTP.dll imports functions of WinInet.dll. In
this case, the global wininet data (variables) will be common, because
both wininet.dll and winhttp.dll are loaded into the same process, and
they share the same address space. It means, that theoretically, an
application will be able to set-up request using WinInet functions
(InternetOpen, InternetConnect, HttpOpenRequest, HttpSendRequest) but
process it using WinHTTP functions (calling WinHTTPReadData with handle
returned from WinInet HttpOpenRequest). This behaviour will be incorrect
wrong, and confusing. This probably one of the reasons they decided to
separate things.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
Don't hesitate to weakup this topic again. MSFT made an real puzzle :)
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
Oooh. This is what you want me to read. Okay, I have to do some research myself. Thanks,
Paul
I did more research.
1. WinHttpOpen maps into WinInet function InternetOpenA - there is no
dependency to wininet.dll, probably, because of project settings, the
function is "included" into winhttp.dll. I can tell for sure, because I
see in disassembly of winhttp.dll that the code is originally the wininet
version.
.text:4D4FEB89 push eax ; lpBuffer
.text:4D4FEB8A push 26h ; dwOption
.text:4D4FEB8C push [ebp+hInternet] ; hInternet
InternetQueryOptionA(x,x,x,x)
.text:4D4FEB97 mov [ebp+var_424], eax
.text:4D4FEB9D test eax, eax
Which is an absolute equivalent to wininet version.
3. WinHttpConnect - converts paramters from unicode to ansi and
delegates the call to InternetConnectA.
The function is an included but original version of WinInet
.text:4D4F98F6 push ebx ; lpszUserName
.text:4D4F98F7 push dword ptr [ebp+nServerPort] ; nServerPort
.text:4D4F98FA push [ebp+lpszServerName] ; lpszServerName
.text:4D4F98FD push [ebp+hInternet] ; hInternet
InternetConnectA(x,x,x,x,x)
.text:4D4F9905 mov edi, eax
And so on. So, the short answer: wininet and winhttp has the common
core functions sets. However, WinHTTP includes the Wininet functions
without referencing wininet.dll in it's import table.
Paul, you can check this by checking the implementation of "internal"
wininet functions which are called by WinHTTP wrappers: they are the same
as wininet equivalents.I suppose, this was done in order to save time to
develop WinHTTP from scratch.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]"
Hmmm.
I see a lot of similarly named functions in the source code, it's
tricky to see which one is the exported one and what you're really looking
at.
So.. for those who are reading... WinHTTP does not use WinInet. Right??
Paul
I take my words back. WinHTTP does not delegate into WinInet
functions, I was confused by the internal names of WinHTTP functions, they
no imports from wininet.dll. Sorry.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]"
Volodymyr,
Oh really? I am disillusioned now. Sorry for doubting you. This
really should be clearer in the documentation.
Is it calling internal variations of WinInet requests that
bypassing or adjusting some client type stuff like (off the top of my
head) authentication, cookies, HTTP redirection (especially to FTP),
connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just
calling "real" WinInet?
Even in Vista?
Paul
Hello Paul,
Use your MVP benefit, and access codepremium center. Take a
look at the implementation of the following functions,
a) WinHttpOpen - converts parameters from ansi to unicode and
delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to
unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and
delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi
and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and
delegates call to HttpWrapSendRequest, which, internally calls quite a big
amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle
This list may be continued.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]"
With all due respect, I don't think that is true. WinHTTP is
billed as a server-side HTTP implementation to replace the client-oriented
WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx
Paul
FYI: WinHTTP is based on WinInet. Quite a big amount of
WinHTTP code simply delegates execution into WinInet equivalented functions.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
I ported toWinHTTP and am no longer able to replicate the problem.
It was very easy and works very well, I like it.
Hello,
I am having trouble with an intermittent error. We're
using WinInet in an ocx on a web page.
When the rather busy web page is building and the ocx
additionally makes its (blocking) HttpOpenRequest to "GET" some additional
data for the UI, the HttpSendRequest is sometimes failing with "operation
timed out."
I've not been able to recover from this while in the
ocx's current thread.
That is to say after timing out, I've tried to
gracefully break down all the connection handles and reestablish all new
ones but still end up timing out on HttpSendRequest. I have tried the
sample code from earlier versions of IE that makes a new thread, to no
avail. And have tried a Sleep() to perhaps let the web page get some of
it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from
the client on the HttpSendRequest.
Nothing seems to work, if it timesout once, that is it?
Any info would surely be appreciated, Thnx
- Mike

[Paul Baker [MVP, Windows Desktop Experience]]

I checked the Windows source code (finally), and I agree that WinInet and
WinHTTP share code.

I don't think WinHTTP is a layer on top of WinInet, I think it just sharses
code with WinInet and probably uses internal code to tweak it. It probably
also doesn't use it for certain functionality. I don't want to go digging
any deeper and it wouldn't be appropriate for me to post what I saw in
public if I did, anyway.

Paul

Post by Volodymyr M. Shcherbyna
I guess, I know why WinHTTP does import WinInet functions directly.
Imagine an application which is sending http requests over Wininet AND
WinHTTP. Assume, that WinHTTP.dll imports functions of WinInet.dll. In
this case, the global wininet data (variables) will be common, because
both wininet.dll and winhttp.dll are loaded into the same process, and
they share the same address space. It means, that theoretically, an
application will be able to set-up request using WinInet functions
(InternetOpen, InternetConnect, HttpOpenRequest, HttpSendRequest) but
process it using WinHTTP functions (calling WinHTTPReadData with handle
returned from WinInet HttpOpenRequest). This behaviour will be incorrect
wrong, and confusing. This probably one of the reasons they decided to
separate things.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
Don't hesitate to weakup this topic again. MSFT made an real puzzle :)
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
Oooh. This is what you want me to read. Okay, I have to do some research myself. Thanks,
Paul
I did more research.
1. WinHttpOpen maps into WinInet function InternetOpenA - there is no
dependency to wininet.dll, probably, because of project settings, the
function is "included" into winhttp.dll. I can tell for sure, because I
see in disassembly of winhttp.dll that the code is originally the wininet
version.
.text:4D4FEB89 push eax ; lpBuffer
.text:4D4FEB8A push 26h ; dwOption
.text:4D4FEB8C push [ebp+hInternet] ; hInternet
InternetQueryOptionA(x,x,x,x)
.text:4D4FEB97 mov [ebp+var_424], eax
.text:4D4FEB9D test eax, eax
Which is an absolute equivalent to wininet version.
3. WinHttpConnect - converts paramters from unicode to ansi and
delegates the call to InternetConnectA.
The function is an included but original version of WinInet
.text:4D4F98F6 push ebx ; lpszUserName
.text:4D4F98F7 push dword ptr [ebp+nServerPort] ; nServerPort
.text:4D4F98FA push [ebp+lpszServerName] ; lpszServerName
.text:4D4F98FD push [ebp+hInternet] ; hInternet
InternetConnectA(x,x,x,x,x)
.text:4D4F9905 mov edi, eax
And so on. So, the short answer: wininet and winhttp has the common
core functions sets. However, WinHTTP includes the Wininet functions
without referencing wininet.dll in it's import table.
Paul, you can check this by checking the implementation of "internal"
wininet functions which are called by WinHTTP wrappers: they are the same
as wininet equivalents.I suppose, this was done in order to save time to
develop WinHTTP from scratch.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]"
Hmmm.
I see a lot of similarly named functions in the source code, it's
tricky to see which one is the exported one and what you're really looking
at.
So.. for those who are reading... WinHTTP does not use WinInet. Right??
Paul
I take my words back. WinHTTP does not delegate into WinInet
functions, I was confused by the internal names of WinHTTP functions, they
no imports from wininet.dll. Sorry.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights."Paul Baker [MVP, Windows - SDK]"
Volodymyr,
Oh really? I am disillusioned now. Sorry for doubting you. This
really should be clearer in the documentation.
Is it calling internal variations of WinInet requests that
bypassing or adjusting some client type stuff like (off the top of my
head) authentication, cookies, HTTP redirection (especially to FTP),
connection limit, MIMe type handling, dialogs and UI stuff, etc.? Or just
calling "real" WinInet?
Even in Vista?
Paul
Hello Paul,
Use your MVP benefit, and access codepremium center. Take a
look at the implementation of the following functions,
a) WinHttpOpen - converts parameters from ansi to unicode and
delegates call to InternetOpenA
b) WinHttpQueryOption - converts parameters from ansi to
unicode, and delegates call to InternetQueryOptionA
c) WinHttpConnect - converts paramters from unicode to ansi and
delegates the call to InternetConnectA
d) WinHttpOpenRequest - converts paramters from unicode to ansi
and delegates call to HttpOpenRequestA
e) WinHttpSendRequest - converts params to ansi :), and
delegates call to HttpWrapSendRequest, which, internally calls quite a big
amount of wininet functions
f) WinHttpCloseHandle - delegates call to InternetCloseHandle
This list may be continued.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Paul Baker [MVP, Windows - SDK]"
With all due respect, I don't think that is true. WinHTTP is
billed as a server-side HTTP implementation to replace the client-oriented
WinInet. It could not do some of the things it does if it used WinInet.
http://msdn2.microsoft.com/en-us/library/aa382925.aspx
Paul
FYI: WinHTTP is based on WinInet. Quite a big amount of
WinHTTP code simply delegates execution into WinInet equivalented functions.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
I ported toWinHTTP and am no longer able to replicate the problem.
It was very easy and works very well, I like it.
Hello,
I am having trouble with an intermittent error. We're
using WinInet in an ocx on a web page.
When the rather busy web page is building and the ocx
additionally makes its (blocking) HttpOpenRequest to "GET" some additional
data for the UI, the HttpSendRequest is sometimes failing with "operation
timed out."
I've not been able to recover from this while in the
ocx's current thread.
That is to say after timing out, I've tried to
gracefully break down all the connection handles and reestablish all new
ones but still end up timing out on HttpSendRequest. I have tried the
sample code from earlier versions of IE that makes a new thread, to no
avail. And have tried a Sleep() to perhaps let the web page get some of
it's work out of the way.
Iv'e looked at it the traffic and nothing eminates from
the client on the HttpSendRequest.
Nothing seems to work, if it timesout once, that is it?
Any info would surely be appreciated, Thnx
- Mike