Setting http version with HttpOpenRequest
John MacCallum
I'm having a problem persuading wininet on a Pocket PC device to use
HTTP/1.0, even though according to the documentation this is the
default. If I call HttpOpenRequest with, for example:
requestHandle = HttpOpenRequest(connectHandle, method, path,
TEXT("HTTP/1.0"), NULL,
accessTypes, 0, 0);
The actual request goes out as HTTP/1.1. Setting the version to
HTTP/2.0 succeeds, so it looks like some property of the connection
is checking for version number >= 1.1 and forcing the use of 1.1 if it
doesn't succeed. I'm initializing the use of wininet with:
openHandle = InternetOpen(TEXT("xxxx"), INTERNET_OPEN_TYPE_PRECONFIG,
NULL, NULL, 0);
and initialising the session with:
connectHandle = InternetConnect(openHandle, authority,
INTERNET_DEFAULT_HTTP_PORT,
NULL, NULL, INTERNET_SERVICE_HTTP, 0 0);
Can anyone shed any light on this?
Thanks,
--
John MacCallum
Brian Combs
See the following article
Q258425 Unable to Specify HTTP Version by Using HttpOpenRequest()
http://support.microsoft.com/support/kb/articles/q258/4/25.asp
Thanks
Brian [MS]
Microsoft Developer Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Philip Sloss
news:3T1SN0JtBHA.2252@cpmsftngxa07...
> Hello
> See the following article
> Q258425 Unable to Specify HTTP Version by Using HttpOpenRequest()
> http://support.microsoft.com/support/kb/articles/q258/4/25.asp
>
Thanks for the pointer, Brian; I had a few follow-ups.
The KB article was last modified in September, but it only mentions a single
IE version and Win2K. Does this article apply to any other versions of IE
or XP, for example?
Does this mean that setting the HTTP_VERSION_INFO option flag won't work,
either?
Is there any way for a process to control the HTTP version it uses without
affecting other processes? I wouldn't want to force the whole system to
1.0, but it might make sense for special purpose applications...
Thanks,
Philip Sloss
Brian Combs
The article is valid for all versions of IE. Changing the settings in IE
allow you to control what version of HTTP you want to use in your
application. However I always recommend HTTP 1.1 unless the server only
supports HTTP 1.0.
Philip Sloss
> Hello
> The article is valid for all versions of IE. Changing the settings in IE
> allow you to control what version of HTTP you want to use in your
> application. However I always recommend HTTP 1.1 unless the server only
> supports HTTP 1.0.
>
Doesn't changing the HTTP version setting in IE apply to all applications,
though? Since the KB article says that an application can't override that
setting on an application-by-application (or process-by-process) basis,
wouldn't setting the version to 1.0 or 1.1 force all WinInet applications to
use that setting?
Brian Combs
If you want to be able to change the Http protocol in an application then
you need to make sure the Http protocol check boxes are unchecked in IE. If
they are checked then that is what will be used. Unchecked means that each
application can pick.
Philip Sloss
> Hello
> If you want to be able to change the Http protocol in an application then
> you need to make sure the Http protocol check boxes are unchecked in IE.
If
> they are checked then that is what will be used. Unchecked means that each
> application can pick.
>
Thanks, Brian. Sorry, but I'm just trying to get this straight...if the
protocol check boxes are unchecked allowing each application to pick, then
assuming that most applications don't pick, what would they get? Wouldn't
it effectively be 1.0 if the protocol check boxes are unchecked?
Thanks for all your help,
Philip Sloss
Brian Combs
If the box is unchecked the application then gets to set the protocol
version with HttpOpenRequest. If the lpszVersion parameter is NULL then
HTTP 1.0 will be used. So if you want to be able to set the protocol
version you leave the boxes unchecked and set the lpszVersion parameter in
the HttpOpenRequest call.
So it works like this.
Protocol boxes checked in IE = yes
Then all apps will use the version that is checked and the lpszVersion
parameter has no effect.
Protocol boxes checked in IE = no
the lpszVersion parameter is used to set the protocol version. If it is
NULL then Http 1.0 is used.
Hope this clears up your questions on what protocol version is being used.
Philip Sloss
> Hello
> If the box is unchecked the application then gets to set the protocol
> version with HttpOpenRequest. If the lpszVersion parameter is NULL then
> HTTP 1.0 will be used. So if you want to be able to set the protocol
> version you leave the boxes unchecked and set the lpszVersion parameter in
> the HttpOpenRequest call.
>
> So it works like this.
> Protocol boxes checked in IE = yes
> Then all apps will use the version that is checked and the lpszVersion
> parameter has no effect.
>
> Protocol boxes checked in IE = no
> the lpszVersion parameter is used to set the protocol version. If it is
> NULL then Http 1.0 is used.
>
> Hope this clears up your questions on what protocol version is being used.
Almost <g>. It looks as if there is no way for one application to specify
which HTTP version it uses in conjunction with WinInet without effecting
pretty much all the other WinInet applications on the system. I'm trying to
verify that this coupling either is or is not the case.
In other words, with the protocol box checked in IE (yes), all WinInet apps
will use HTTP 1.1 whether they specify it or not. With the protocol box
unchecked in IE (no), most WinInet apps will use HTTP 1.0. I'm basing this
on the assumption that most released applications are passing either NULL or
the #define HTTP_VERSION as the lpszVersion parameter in the call to
HttpOpenRequest.
Is this assumption correct/reasonable or not? One of the reasons I'm making
this assumption is the presence of the Registry value (and its associated
checkbox UI in IE) in the first place...why would it be necessary to have a
value that forces all WinInet apps to work one way or the other? Of course,
the Registry value may exist for completely unrelated reasons, but in either
case I'd be interested in what those reasons were.
Thanks,
Philip Sloss
Brian Combs
"In other words, with the protocol box checked in IE (yes), all WinInet apps
"With the protocol box
unchecked in IE (no), most WinInet apps will use HTTP 1.0. I'm basing this
on the assumption that most released applications are passing either NULL or
the #define HTTP_VERSION as the lpszVersion parameter in the call to
HttpOpenRequest.." I cannot speak for how folks write there applications.
But you may be correct.
"One of the reasons I'm making
this assumption is the presence of the Registry value (and its associated
checkbox UI in IE) in the first place...why would it be necessary to have a
value that forces all WinInet apps to work one way or the other? Of course,
the Registry value may exist for completely unrelated reasons, but in either
case I'd be interested in what those reasons were."
WinInet was designed for use with IE and IE stores different user settings
in the registry like may other applications do. Knowing that WinInet was
designed for IE explains why it uses so many IE setting for how it works.
It is also the cause of many problems as developers may not want it to use
the settings from IE. So when using WinInet you are walking a fine line
between how you want it to work and the DLL deciding how to work based on a
users settings in the registry for how they want IE to work.
Philip Sloss
> WinInet was designed for use with IE and IE stores different user settings
> in the registry like may other applications do. Knowing that WinInet was
> designed for IE explains why it uses so many IE setting for how it works.
> It is also the cause of many problems as developers may not want it to use
> the settings from IE. So when using WinInet you are walking a fine line
> between how you want it to work and the DLL deciding how to work based on
a
> users settings in the registry for how they want IE to work.
>
Thanks for your patience...I guess this is one of those cases where the
program I have steps over the line...I'll look into alternatives to
WinInet...
Thanks again,
Philip Sloss