HttpSendRequest never returns

Discussion:

(too old to reply)

Detlef Schneider

2005-09-17 12:50:45 UTC

Hello out there,
I am using wininet with Win CE 4.20 on X86 platform (QFEs up to 08/2005) with
RAS over GPRS wireless connection.
In test-scenario I am using one connectionhandle from InternetOpen call with
INTERNET_FLAG_ASYNC set and one
sessionhandle from InternetConnect (HTTP port 80). Requesthandles are always
recycled via HttpOpen and
InternetCloseHandle. About 90% of the requests ar well, for the lasting 10%
HttpSendRequest will not return.

The states from async-callback are in normal:
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (308 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_REQUEST_COMPLETE

I also get something like that (OK too):
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (196 bytes)
INTERNET_STATUS_REQUEST_COMPLETE

the error-case:
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_RECEIVING_RESPONSE
...nothing more...

I have to InternetCloseHandle to end the Request. But in all surveilled cases,
the server has received the data
and answered correct - I checked this with network monitor on server-side.
I never realized the problem over local LAN (without RAS), but sniffing
RAS-PPP/RS232 between modem (Siemens MC35i)
and CE-device seems to indicate, that all data reach the device.

Where to look further? Is it a problem within wininet or a problem with RAS?
How to detect, where the problem is
(both cadidates are somewhat like 'black-boxes')?

Regards,
Detlef Schneider

Terry Fei[MSFT]

2005-09-19 03:42:39 UTC

Permalink

Hi Detlef,
Welcome to Microsoft News Group!

Based on my understanding, the problem you met is: HttpSendRequest API
hangs at some time while sending request to server with it.If I
misunderstood you, please feel free to let me know.

From my opinion, the probable cause of this problem is: At the beginning of
HttpSendRequest API, it'll call AuthLock to set critical section. So if
some subsequent code crashes before WinInet has exited it's internal
critical section, the critical section won't get released. Any subsequent
HttpSendRequest will hang and cann't return.The workaround, I think, is to
wrap the HttpSendRequest with a try/catch. In the catch block, we should
close the very top InternetOpen handle for that thread and hence the
HttpSendRequest API will pop out with operation cancelled status code.Then
we can send request again using HttpSendRequest API. (You also can create a
background-manager-thread instead of try-catch. This thread will detect
such hang condition and close the very top InternetOpen handle for that
thread and hence the HttpSendRequest API will pop out with operation
cancelled status code.)

The following article is about "How To Control Connection Timeout Value by
Creating Second Thread". You can controls how long to wait while using
HttpSendRequest to send request to server in WinInet. I hope it's useful
for you.
Title: How To Control Connection Timeout Value by Creating Second Thread
URL: http://support.microsoft.com/kb/224318/EN-US/

Another cause which would make HttpSendRequest API is "WinInet Limits
Connections Per Server". You can refer to this article,
Title: INFO: WinInet Limits Connections Per Server
URL:http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q183110

I hope the above information helps, if you have any questions or concerns,
please do not hesitate to let me know. I am standing by to help you. Thanks!

Best Regards,

Terry Fei
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------

Subject: HttpSendRequest never returns
User-Agent: NewsPro/3.7.3
Newsgroups: microsoft.public.windows.inetexplorer.ie5.programming.wininet
Date: Sat, 17 Sep 2005 05:50:45 -0700
NNTP-Posting-Host: p50891AB9.dip0.t-ipconnect.de 80.137.26.185
Lines: 1
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl

microsoft.public.windows.inetexplorer.ie5.programming.wininet:286

X-Tomcat-NG: microsoft.public.windows.inetexplorer.ie5.programming.wininet
Hello out there,
I am using wininet with Win CE 4.20 on X86 platform (QFEs up to 08/2005) with
RAS over GPRS wireless connection.
In test-scenario I am using one connectionhandle from InternetOpen call with
INTERNET_FLAG_ASYNC set and one
sessionhandle from InternetConnect (HTTP port 80). Requesthandles are always
recycled via HttpOpen and
InternetCloseHandle. About 90% of the requests ar well, for the lasting 10%
HttpSendRequest will not return.
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (308 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_REQUEST_COMPLETE
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (196 bytes)
INTERNET_STATUS_REQUEST_COMPLETE
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_RECEIVING_RESPONSE
...nothing more...
I have to InternetCloseHandle to end the Request. But in all surveilled cases,
the server has received the data
and answered correct - I checked this with network monitor on server-side.
I never realized the problem over local LAN (without RAS), but sniffing
RAS-PPP/RS232 between modem (Siemens MC35i)
and CE-device seems to indicate, that all data reach the device.
Where to look further? Is it a problem within wininet or a problem with RAS?
How to detect, where the problem is
(both cadidates are somewhat like 'black-boxes')?
Regards,
Detlef Schneider

Detlef Schneider

2005-09-20 12:04:33 UTC

Permalink

Post by Terry Fei[MSFT]
Hi Detlef,
Welcome to Microsoft News Group!
Based on my understanding, the problem you met is: HttpSendRequest API
hangs at some time while sending request to server with it.If I
misunderstood you, please feel free to let me know.
......

Hi Terry,
thanks for you answering to my posting.
The point is, that all errors -it happens quite often, about ervery 10-50
requests, the message arrived at the server and has been answered by the
server. The answer is in 2 parts: Http 100-continue with some infos from IIS
and Http 200 OK with the answer. The 100-continue-answer reaches my client (see
the INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes) and
INTERNET_STATUS_INTERMEDIATE_RESPONSE status responses), but the 200-OK-data
will never be seen by the client.

I took a look at the RS232 connection beetwen RAS and the GPRS-modem: the modem
does not send the 200-OK-part - therefore wininet seems right to not finish the
HttpSendRequest. But there is some part of the protocoll - I dont know if it is
RAS or Wininet, which happens in response to each request. It is not-ascii and
is initiated by the client. Most of time this part of communication happens
during 200-ok-part of server-answer and all works fine. But some times the
message from client over the connection is send during the 100-continue-part -
and no continuing part of the http-response will arrive at the client.

The additional message looks something like:
7e 21 45 00 00 28 1A ab 40 00 80 0b f4 a9 50 bb
21 4c 50 89 28 f0 04 1f 42 50 83 9c 1c 08 3e c1
03 42 50 10 7d 5d fd b0 18 00 00 1b 42 7e

I cannot identify the part of the protocol which disturbes the communication -
but I can see that it is reproducing the error. I dont know if it is wininet
causing the message at a moment where it shuold not happen, or is it ras, or is
it the modem-software which handles the request not correct when the message
arrives bevore the 200-ok-message is not read.

My question is how I can circumvent the problem - when I detect the problem I
can close the handle and can send the request again. But it happens quite often
and therefor is just becoming a cost-factor cause gprs has to be payed by
volume! and i am not really interested in the answer (only in status),Ii am
sending realtime-data via internet and each resend will disturb the server with
rollback-transactions.

Best regards
Detlef Schneider

Post by Terry Fei[MSFT]
--------------------

microsoft.public.windows.inetexplorer.ie5.programming.wininet:286

X-Tomcat-NG: microsoft.public.windows.inetexplorer.ie5.programming.wininet
Hello out there,
I am using wininet with Win CE 4.20 on X86 platform (QFEs up to 08/2005)

with

RAS over GPRS wireless connection.
In test-scenario I am using one connectionhandle from InternetOpen call

with

INTERNET_FLAG_ASYNC set and one
sessionhandle from InternetConnect (HTTP port 80). Requesthandles are

always

recycled via HttpOpen and
InternetCloseHandle. About 90% of the requests ar well, for the lasting

10%

HttpSendRequest will not return.
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (308 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_REQUEST_COMPLETE
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (196 bytes)
INTERNET_STATUS_REQUEST_COMPLETE
INTERNET_STATUS_SENDING_REQUEST
INTERNET_STATUS_REQUEST_SENT (224 bytes)
INTERNET_STATUS_RECEIVING_RESPONSE
INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes)
INTERNET_STATUS_INTERMEDIATE_RESPONSE
INTERNET_STATUS_RECEIVING_RESPONSE
...nothing more...
I have to InternetCloseHandle to end the Request. But in all surveilled

cases,

the server has received the data
and answered correct - I checked this with network monitor on server-side.
I never realized the problem over local LAN (without RAS), but sniffing
RAS-PPP/RS232 between modem (Siemens MC35i)
and CE-device seems to indicate, that all data reach the device.
Where to look further? Is it a problem within wininet or a problem with

RAS?

How to detect, where the problem is
(both cadidates are somewhat like 'black-boxes')?
Regards,
Detlef Schneider

Terry Fei[MSFT]

2005-09-21 10:10:13 UTC

Permalink

Hi Detlef,
Thanks for your detailed feedback! : )

From your description of symptom, I think, the problem is not aroused from
WinInet API. Since the modem does not received data from server,
HttpSendRequest is hanged, which is expected. But why modem doesn't receive
data? From my opinion and your description (the problem never happen over
local LAN), I think, there is wrong with your current hardware(modem)
probably. In order to isolate the issue, we recommended you to use another
good modem instead of the current one. Then try to check it again.

If you are still experiencing problem, I advise you can port the program to
PC-Platform to test so that we can confirm whether or not the problem is
related to WinCE. If it's related to WinCE, we can consult some internal
experts of WinCE to help you together.

Thanks for your understanding! If you have any findings, please feel free
to let me know. I will be happy to be of further assistance. We are looking
forward to hearing from you. Thanks!

Best Regards,

Terry Fei
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------

Subject: RE: HttpSendRequest never returns
User-Agent: NewsPro/3.7.3
Newsgroups: microsoft.public.windows.inetexplorer.ie5.programming.wininet
Date: Tue, 20 Sep 2005 05:04:33 -0700
NNTP-Posting-Host: p508928F0.dip0.t-ipconnect.de 80.137.40.240
Lines: 1
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl

microsoft.public.windows.inetexplorer.ie5.programming.wininet:289

X-Tomcat-NG: microsoft.public.windows.inetexplorer.ie5.programming.wininet

100-continue-part -

and no continuing part of the http-response will arrive at the client.
7e 21 45 00 00 28 1A ab 40 00 80 0b f4 a9 50 bb
21 4c 50 89 28 f0 04 1f 42 50 83 9c 1c 08 3e c1
03 42 50 10 7d 5d fd b0 18 00 00 1b 42 7e
I cannot identify the part of the protocol which disturbes the

communication -

but I can see that it is reproducing the error. I dont know if it is wininet
causing the message at a moment where it shuold not happen, or is it ras, or is
it the modem-software which handles the request not correct when the message
arrives bevore the 200-ok-message is not read.
My question is how I can circumvent the problem - when I detect the problem I
can close the handle and can send the request again. But it happens quite often
and therefor is just becoming a cost-factor cause gprs has to be payed by
volume! and i am not really interested in the answer (only in status),Ii am
sending realtime-data via internet and each resend will disturb the server with
rollback-transactions.
Best regards
Detlef Schneider

Post by Terry Fei[MSFT]
--------------------

microsoft.public.windows.inetexplorer.ie5.programming.wininet:286

microsoft.public.windows.inetexplorer.ie5.programming.wininet

Post by Terry Fei[MSFT]

Hello out there,
I am using wininet with Win CE 4.20 on X86 platform (QFEs up to 08/2005)

with

RAS over GPRS wireless connection.
In test-scenario I am using one connectionhandle from InternetOpen call

with

INTERNET_FLAG_ASYNC set and one
sessionhandle from InternetConnect (HTTP port 80). Requesthandles are

always

recycled via HttpOpen and
InternetCloseHandle. About 90% of the requests ar well, for the lasting

10%

cases,

the server has received the data
and answered correct - I checked this with network monitor on

server-side.

Post by Terry Fei[MSFT]

I never realized the problem over local LAN (without RAS), but sniffing
RAS-PPP/RS232 between modem (Siemens MC35i)
and CE-device seems to indicate, that all data reach the device.
Where to look further? Is it a problem within wininet or a problem with

RAS?

How to detect, where the problem is
(both cadidates are somewhat like 'black-boxes')?
Regards,
Detlef Schneider

Detlef Schneider

2005-09-22 09:12:46 UTC

Permalink

Hi Terry,

no, I don't think it is a problem with the modem. I know it very well and it is
a problem in protocol - but modem does not know about http. There are others
out ther in community, who suffere(d) the same problem - wininet seems to not
handle http-status 100 continue correctly. (e.g. you can have a look at
deja/google-groups with search-phrase '100-Contue Status problem'). I wanted to
try to fallback to HTTP/1.0 for the IIS must not send the 100-continue in that
case, but I do not find any way to tell wininet to use HTTP/1.0. It should be
the default - but even explicitly setting the version (with HttpOpenRequest or
with InternetSetOption) will continue using HTTP/1.1. And regarding Q258425
[[Unable to Specify HTTP Version by Using HttpOpenRequest() -
http://support.microsoft.com/support/kb/articles/q258/4/25.asp ]] does not work
too. Wininet does use HTTP1.1. How can I switch to Version 1.0 then?

Best Regards,
Detlef Schneider

Post by Terry Fei[MSFT]
Hi Detlef,
Thanks for your detailed feedback! : )
From your description of symptom, I think, the problem is not aroused from
WinInet API. Since the modem does not received data from server,
HttpSendRequest is hanged, which is expected. But why modem doesn't receive
data? From my opinion and your description (the problem never happen over
local LAN), I think, there is wrong with your current hardware(modem)
probably. In order to isolate the issue, we recommended you to use another
good modem instead of the current one. Then try to check it again.
If you are still experiencing problem, I advise you can port the program to
PC-Platform to test so that we can confirm whether or not the problem is
related to WinCE. If it's related to WinCE, we can consult some internal
experts of WinCE to help you together.
Thanks for your understanding! If you have any findings, please feel free
to let me know. I will be happy to be of further assistance. We are looking
forward to hearing from you. Thanks!
Best Regards,
Terry Fei
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------

microsoft.public.windows.inetexplorer.ie5.programming.wininet:289

X-Tomcat-NG: microsoft.public.windows.inetexplorer.ie5.programming.wininet

IIS

and Http 200 OK with the answer. The 100-continue-answer reaches my client

(see

the INTERNET_STATUS_RESPONSE_RECEIVED (112 bytes) and
INTERNET_STATUS_INTERMEDIATE_RESPONSE status responses), but the

200-OK-data

will never be seen by the client.
I took a look at the RS232 connection beetwen RAS and the GPRS-modem: the

modem

does not send the 200-OK-part - therefore wininet seems right to not

finish the

HttpSendRequest. But there is some part of the protocoll - I dont know if

it is

RAS or Wininet, which happens in response to each request. It is not-ascii

and

is initiated by the client. Most of time this part of communication

happens

during 200-ok-part of server-answer and all works fine. But some times the
message from client over the connection is send during the

100-continue-part -

communication -

but I can see that it is reproducing the error. I dont know if it is

wininet

causing the message at a moment where it shuold not happen, or is it ras,

or is

it the modem-software which handles the request not correct when the

message

arrives bevore the 200-ok-message is not read.
My question is how I can circumvent the problem - when I detect the

problem I

can close the handle and can send the request again. But it happens quite

often

and therefor is just becoming a cost-factor cause gprs has to be payed by
volume! and i am not really interested in the answer (only in status),Ii

sending realtime-data via internet and each resend will disturb the server

with

rollback-transactions.
Best regards
Detlef Schneider

Post by Terry Fei[MSFT]
--------------------

microsoft.public.windows.inetexplorer.ie5.programming.wininet:286

microsoft.public.windows.inetexplorer.ie5.programming.wininet

Post by Terry Fei[MSFT]

Hello out there,
I am using wininet with Win CE 4.20 on X86 platform (QFEs up to 08/2005)

with

RAS over GPRS wireless connection.
In test-scenario I am using one connectionhandle from InternetOpen call

with

INTERNET_FLAG_ASYNC set and one
sessionhandle from InternetConnect (HTTP port 80). Requesthandles are

always

recycled via HttpOpen and
InternetCloseHandle. About 90% of the requests ar well, for the lasting

10%

cases,

the server has received the data
and answered correct - I checked this with network monitor on

server-side.

Post by Terry Fei[MSFT]

RAS?

How to detect, where the problem is
(both cadidates are somewhat like 'black-boxes')?
Regards,
Detlef Schneider

Terry Fei[MSFT]

2005-09-25 04:07:52 UTC

Permalink

Hi Detlef,

I have researched your issue. Here are the answers to you questions.

When HTTP1.1 setting of IE's options is enabled, it's request header is
alwayss sent with "HTTP/1.1" regardless of fourth parameter in
HttpOpenRequest(). This behavior is by design. Registry value EnableHttp1_1
overwrites the version parameter passed to the HttpOpenRequest.

You can try to use following code to HTTP version, however, it should work
for the current process only.
HTTP_VERSION_INFO verinfo = {1, 0};
InternetSetOption(NULL, INTERNET_OPTION_HTTP_VERSION, &verinfo,
sizeof(verinfo));

Another way to change HTTP version is that you can change the registry
location EnableHttp1_1 for the current user. Please be aware that modifying
this key will affect all WinInet applications on the system, including IE
itself. The same registry key could be changed without going to the
registry, instead you can change settings in IE. Go to "View/Internet
Options", "Advanced" tab, locate "Http 1.1. Settings" and unclick "Use Http
1.1". This way is valid on PC-Platform. If it cann't work on CE-Platform,
you can consult it in WinCE Newsgroup.

Please let me know if you have more questions. It's my pleasure to work
with you. Thanks!

Best Regards,

Terry Fei
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Detlef Schneider

2005-09-27 09:32:41 UTC

Permalink

Hi Terry,
thanks for your investigation.

Ok, but then it would be very nice, if wininet-documentation would have
mentioned it. It would have saved some work...

Post by Terry Fei[MSFT]
You can try to use following code to HTTP version, however, it should work
for the current process only.
HTTP_VERSION_INFO verinfo = {1, 0};
InternetSetOption(NULL, INTERNET_OPTION_HTTP_VERSION, &verinfo,
sizeof(verinfo));

I had tried this before, but it does not seem to change anything with the
behavior.

Post by Terry Fei[MSFT]
Another way to change HTTP version is that you can change the registry
location EnableHttp1_1 for the current user. Please be aware that modifying
this key will affect all WinInet applications on the system, including IE
itself. >

Ok, I found that hint in newsgroups before - but wininet did not change to http
1.0; perhaps your remark 'for the current user' comes into play here: I do not
have any special user. It is a headless device without IE. That causes a lot of
trouble with WinCE: it is a very mighty platform and I like programming it -
but very often, it is tightly fitted for devices with display. Especially the
documentation is often only relayed to desktop-like user-interfaces. Thats a
problem, many developers in my surrounding are suffering!

The same registry key could be changed without going to the

Post by Terry Fei[MSFT]
registry, instead you can change settings in IE. Go to "View/Internet
Options", "Advanced" tab, locate "Http 1.1. Settings" and unclick "Use Http
1.1". This way is valid on PC-Platform. If it cann't work on CE-Platform,
you can consult it in WinCE Newsgroup.

See above: headless!

Post by Terry Fei[MSFT]
Please let me know if you have more questions. It's my pleasure to work
with you. Thanks!
Best Regards,
Terry Fei
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Ok, for the moment, I work with all flaws. I use wininet in async-mode with
timeouts and have layed and end-to-end-protocol over the communication layer.
No it works proof - but with a lot of IMHO unneccessary traffic. But I don't
know where the problem is: wininet, ras, modem or provider.
Thanks a lot for you discussing the problem with me.

Best regards,
Detlef Schneider

Detlef Schneider

2005-09-27 16:53:54 UTC

Permalink

Hi Terry,

Post by Terry Fei[MSFT]
Hi Detlef,
I have researched your issue. Here are the answers to you questions.
When HTTP1.1 setting of IE's options is enabled, it's request header is
alwayss sent with "HTTP/1.1" regardless of fourth parameter in
HttpOpenRequest(). This behavior is by design. Registry value EnableHttp1_1
overwrites the version parameter passed to the HttpOpenRequest.
...
Another way to change HTTP version is that you can change the registry
location EnableHttp1_1 for the current user. Please be aware that modifying
this key will affect all WinInet applications on the system, including IE
itself.

My Settings are:
[HCU/Software/Microsoft/Windows/CurrentVersion/InternetSettings]
"EnableHttp1_1"=dword:0
"ProxyHttp1.1"=dword:0

but wininet still uses HTTP/V1.1 - any hints?
HttpOpenRequest specifies NULL for version, should be default=HTTP 1.0

Best regards,
Detlef Schneider

Terry Fei[MSFT]

2005-09-28 02:43:04 UTC

Permalink

Hi Detlef,

I'm glad to discuss this problem with you. : )
According to the document, if we set the registry value as follows,
[HCU/Software/Microsoft/Windows/CurrentVersion/InternetSettings]
"EnableHttp1_1"=dword:0
"ProxyHttp1.1"=dword:0

WinInet API will use HTTP/v1.0. It works in PC-Platform. So we can change
the following registry's value to 0 by Registry API before calling
InternetConnect().
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSetting
s\EnableHttp1_1 )
But I don't confirm whether or not it also works in CE-Platform. In this
scenario, I recommend you to consult this problem in WinCE-Newsgroup. I
think it's a more efficient way for you to resolve this issue .

If there is anything I can assist, please feel free to let me know. Thanks!

Best Regards,

Terry Fei
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)