Web Connection
WWIPSTUFF PROBLEM
Gravatar is a globally recognized avatar based on your email address. WWIPSTUFF PROBLEM
  n/a
  All
  Jul 1, 2014 @ 08:09am
I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred


Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Jul 1, 2014 @ 09:31am

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred



Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Jul 22, 2014 @ 12:16pm
Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred



Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Jul 22, 2014 @ 12:58pm

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred






Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Jul 25, 2014 @ 07:45am
I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred






Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Jul 25, 2014 @ 10:24am

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred









Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Jul 25, 2014 @ 12:03pm

We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred









Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Jul 27, 2014 @ 11:49pm
Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred












Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Aug 27, 2014 @ 08:24pm
Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred












Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Sep 2, 2014 @ 03:34pm
Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred















Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Sep 3, 2014 @ 04:10am
Rick
All I want to do is post a set of results (data) to a client webpage so they can update their system.
I use
lcText=o.HttpGet("https://clientdomain.com/postbacks/results.aspx")

***Is there any other way to do it? Another utility, or function? ***

Worked fine on our server for 5 years till we moved to the cloud. Nothing else seems to have changed, same domain, same httpget statement. This is their final answer, it is an application problem. We have been going in circles with them for 2 months and I have had to maintain the old server just for this client because of this.

>

I read through the full recommendation from our MCC Support team as below:
===============================================
Reading through this and doing some basic testing, I see the following:

Concern is that outbound traffic is being tampered with (blocked or otherwise) by CLC.

Tracert shows that ICMP is making it to internet (but blocked at ae-11-11.car1.Raleigh1.Level3.net [4.69.132.173], as is any ICMP request from other locations I tested)

Our testing has shown that the site can be resolved from your server.

Your supplied error is an application level error.

The attached network capture shows that not one single outbound GET request was sent to any address.

Summary of findings based on this information:

Customer machine is erroring at application layer, and the GET request, specifically when sent using this method:
"We are doing a httpget to this site to post search results to this page (from our webconnect application)"
is failing at the application layer.

Recommendation:
The application layer issue on NY1APXXXX01 needs to be troubleshot and resolved. Perhaps the configuration needs to be compared to the machine that is a known good.
As long as traffic is not making it out from the application and being sent from the NIC, there is really nothing further we can do as we do not support the application.
===============================================

From the above,

The two points below
1. Tracert shows that ICMP is making it to internet
2. Our testing has shown that the site can be resolved from your server.

eliminate the suggestion that this issue is caused by a network issue on the MCC platform. This is one of the suggestions reported by the developer of the app in your opening text on this ticket: ". Could also be related to network configuration (proxy/firewall) issues..."

The second suggestion reported by the developer: "This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response."

falls outside of what we would troubleshoot as part of standard support. Please work with the developer to look further into this application and what may be causing this issue


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred















Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Sep 3, 2014 @ 05:01am
This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred















Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Sep 3, 2014 @ 12:22pm

I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred


















Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Sep 3, 2014 @ 05:01pm
Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred


















Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Sep 3, 2014 @ 05:33pm
Fred,

Ok, you're using wwIPStuff which has been deprecated for nearly 10 years now. Maybe you should consider taking a look at a newer wwHTTP class version that has more current improvements and is up to date with OS changes since Windows XP/2000. Same interface just refactored into its own class and is current as opposed to the 10 year old stale code in wwipstuff.

The most likely problem is that the WinInet system settings have changed over the years. There were a number of issues introduced with newer versions of windows that have been addressed since. I can't say for sure whether that will address your issue, but that's the first thing to check. Download the latest shareware version and see if it addresses your issue. If it does you have your solution and you can update to the later tools. Otherwise we can check back here.

You should also recreate your instance of wwHttp/wwipstuff for each http request rather than reuse the object since HTTP is stateless and WinInet reflects that. Cleaner - and can cause issues at times.

... and please use the code format button when you post code before you inflict it on us to read without indentation and formatting.

Thanks,

+++ Rick ---



Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred





















Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Sep 3, 2014 @ 08:28pm
Rick
Could not locate where I can download the shareware version of wwhttp class, and documentation/examples. Please direct me to where this can be downloaded
Thanks a million for all your help
Fred


Fred,

Ok, you're using wwIPStuff which has been deprecated for nearly 10 years now. Maybe you should consider taking a look at a newer wwHTTP class version that has more current improvements and is up to date with OS changes since Windows XP/2000. Same interface just refactored into its own class and is current as opposed to the 10 year old stale code in wwipstuff.

The most likely problem is that the WinInet system settings have changed over the years. There were a number of issues introduced with newer versions of windows that have been addressed since. I can't say for sure whether that will address your issue, but that's the first thing to check. Download the latest shareware version and see if it addresses your issue. If it does you have your solution and you can update to the later tools. Otherwise we can check back here.

You should also recreate your instance of wwHttp/wwipstuff for each http request rather than reuse the object since HTTP is stateless and WinInet reflects that. Cleaner - and can cause issues at times.

... and please use the code format button when you post code before you inflict it on us to read without indentation and formatting.

Thanks,

+++ Rick ---



Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred





















Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Sep 3, 2014 @ 08:31pm


Fred,

Ok, you're using wwIPStuff which has been deprecated for nearly 10 years now. Maybe you should consider taking a look at a newer wwHTTP class version that has more current improvements and is up to date with OS changes since Windows XP/2000. Same interface just refactored into its own class and is current as opposed to the 10 year old stale code in wwipstuff.

The most likely problem is that the WinInet system settings have changed over the years. There were a number of issues introduced with newer versions of windows that have been addressed since. I can't say for sure whether that will address your issue, but that's the first thing to check. Download the latest shareware version and see if it addresses your issue. If it does you have your solution and you can update to the later tools. Otherwise we can check back here.

You should also recreate your instance of wwHttp/wwipstuff for each http request rather than reuse the object since HTTP is stateless and WinInet reflects that. Cleaner - and can cause issues at times.

... and please use the code format button when you post code before you inflict it on us to read without indentation and formatting.

Thanks,

+++ Rick ---



Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred














Also I have WC 4.66 - will the latest version of wwhttp work with that?







Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Sep 3, 2014 @ 11:46pm

Here's a link:
http://west-wind.com/WestwindClientTools.aspx

Docs:
http://www.west-wind.com/webconnection/wwClient_docs/?page=_s9001zxi9.htm

+++ Rick ---



Rick
Could not locate where I can download the shareware version of wwhttp class, and documentation/examples. Please direct me to where this can be downloaded
Thanks a million for all your help
Fred


Fred,

Ok, you're using wwIPStuff which has been deprecated for nearly 10 years now. Maybe you should consider taking a look at a newer wwHTTP class version that has more current improvements and is up to date with OS changes since Windows XP/2000. Same interface just refactored into its own class and is current as opposed to the 10 year old stale code in wwipstuff.

The most likely problem is that the WinInet system settings have changed over the years. There were a number of issues introduced with newer versions of windows that have been addressed since. I can't say for sure whether that will address your issue, but that's the first thing to check. Download the latest shareware version and see if it addresses your issue. If it does you have your solution and you can update to the later tools. Otherwise we can check back here.

You should also recreate your instance of wwHttp/wwipstuff for each http request rather than reuse the object since HTTP is stateless and WinInet reflects that. Cleaner - and can cause issues at times.

... and please use the code format button when you post code before you inflict it on us to read without indentation and formatting.

Thanks,

+++ Rick ---



Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred
























Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  n/a
  Rick Strahl
  Sep 11, 2014 @ 05:15pm
Thanks a zill, we managed to send communication out to the client. A quick question though, we have this function run every time we send back results and it has as the first two lines of code,
do wwhttp
ohttp=createobject('wwhttp')

Will the repeated use of this code, every time an order is processed cause an object buildup or some other problem, and should we just run it once and then check and see if the object is already there, then not create it? Also what about repeated use of do wwhttp?

Here's a link:
http://west-wind.com/WestwindClientTools.aspx

Docs:
http://www.west-wind.com/webconnection/wwClient_docs/?page=_s9001zxi9.htm

+++ Rick ---



Rick
Could not locate where I can download the shareware version of wwhttp class, and documentation/examples. Please direct me to where this can be downloaded
Thanks a million for all your help
Fred


Fred,

Ok, you're using wwIPStuff which has been deprecated for nearly 10 years now. Maybe you should consider taking a look at a newer wwHTTP class version that has more current improvements and is up to date with OS changes since Windows XP/2000. Same interface just refactored into its own class and is current as opposed to the 10 year old stale code in wwipstuff.

The most likely problem is that the WinInet system settings have changed over the years. There were a number of issues introduced with newer versions of windows that have been addressed since. I can't say for sure whether that will address your issue, but that's the first thing to check. Download the latest shareware version and see if it addresses your issue. If it does you have your solution and you can update to the later tools. Otherwise we can check back here.

You should also recreate your instance of wwHttp/wwipstuff for each http request rather than reuse the object since HTTP is stateless and WinInet reflects that. Cleaner - and can cause issues at times.

... and please use the code format button when you post code before you inflict it on us to read without indentation and formatting.

Thanks,

+++ Rick ---



Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred
























Gravatar is a globally recognized avatar based on your email address. Re: WWIPSTUFF PROBLEM
  Rick Strahl
  fredk
  Sep 11, 2014 @ 05:20pm
You don't need to reload the library each time (ie. DO wwhttp). But you actually SHOULD always recreate the wwhttp object - since HTTP is stateless it's a good idea to recreate the object each time.

Multiple calls work, but there can be caching and connection issues that are not behaving the way you might expect by WinInet, so my recommendation is to always create it.

+++ Rick ---



Thanks a zill, we managed to send communication out to the client. A quick question though, we have this function run every time we send back results and it has as the first two lines of code,
do wwhttp
ohttp=createobject('wwhttp')

Will the repeated use of this code, every time an order is processed cause an object buildup or some other problem, and should we just run it once and then check and see if the object is already there, then not create it? Also what about repeated use of do wwhttp?

Here's a link:
http://west-wind.com/WestwindClientTools.aspx

Docs:
http://www.west-wind.com/webconnection/wwClient_docs/?page=_s9001zxi9.htm

+++ Rick ---



Rick
Could not locate where I can download the shareware version of wwhttp class, and documentation/examples. Please direct me to where this can be downloaded
Thanks a million for all your help
Fred


Fred,

Ok, you're using wwIPStuff which has been deprecated for nearly 10 years now. Maybe you should consider taking a look at a newer wwHTTP class version that has more current improvements and is up to date with OS changes since Windows XP/2000. Same interface just refactored into its own class and is current as opposed to the 10 year old stale code in wwipstuff.

The most likely problem is that the WinInet system settings have changed over the years. There were a number of issues introduced with newer versions of windows that have been addressed since. I can't say for sure whether that will address your issue, but that's the first thing to check. Download the latest shareware version and see if it addresses your issue. If it does you have your solution and you can update to the later tools. Otherwise we can check back here.

You should also recreate your instance of wwHttp/wwipstuff for each http request rather than reuse the object since HTTP is stateless and WinInet reflects that. Cleaner - and can cause issues at times.

... and please use the code format button when you post code before you inflict it on us to read without indentation and formatting.

Thanks,

+++ Rick ---



Here is the code, works fine on the old server

Function smsout
parameters lnorder
o=create("wwIPSTUFF")
SET MEMOWIDTH TO 200

*** Connect to the server
lcdata=o.httpget("https://domain.com/postbacks/backgroundcheck.aspx") **word domain substituted for real name

if used('testDL')
sele testDL
else
sele 0
use testDL
endif
SET ORDER TO ORDERNO
seek lnorder
lcprofile=TRIM(profile_id)
lcresult=results
*** Let's post some data TO the server
o.AddPostKey("profile_id",lcprofile)
o.AddPostKey("profile_info",lcresult)
*** Initialize the variables that will be filled by HTTPGetEx
lcHTML=""
lnText=0

lcText=o.HttpGet("https://domain.com/postbacks/backgroundcheck.aspx")
? o.nError,o.cErrorMsg
=this.errormsg('successful update - results returned')


I don't understand what you're asking... wwHttp does not use any .NET components, so the .NET configuration from the server is completely irrelevant as it doesn't use any of those settings even if you are running from inside of an ASP.NET/Web Connection application. wwHttp uses raw WinInet which are core Windows (Win32) services. If you have a server side failure you should get an error response from the server - ie. an HTTP 500 or other HTTP error response.

If I do:

CLEAR
DO wwhttp
loHttp = CREATEOBJECT("wwhttp")
lcText=loHttp.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx")
ShowHtml( lcText)
RETURN

I get a resource not found (404) error. I suspect you are doing something more or validating first, but since you don't post code how are we supposed to know?

If it fails on the client - then the most likely problem has to do with the internet connection or proxy configuration. Make sure you experiment with the various connection settings (Direct, Auto, Proxy) and see if that has any effect.

The error you mentioned originally is an undefined, generic error. Usually that is caused by WinInet getting a configuration value that is invalid. Invalid domain, invalid parameter switch etc. I assume the code works from other locations?

Most likely the problem is that there's a firewall or proxy that prevents you to get out from the machine, which can also in some cases cause this undefined error.

+++ Rick ---



This is the line throwing the error
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

See the .aspx above, could this be the problem - with asp.net, and maybe the httpget is disabled?

According to, http://support.microsoft.com/kb/819267

"The .NET-connected Web services support HTTP GET, HTTP POST and SOAP protocols. By default, in .NET Framework 1.0, all three protocols are enabled. By default, in .NET Framework 1.1, HTTP GET and HTTP POST are both disabled. This is for security reasons.

Applications that use HTTP GET or HTTP POST to invoke a Web service fail when the Web service is upgraded to .NET Framework 1.1. These applications receive a
System.Net.WebException
error message that indicates the request format is unrecognized.""Workaround
HTTP GET and HTTP POST may be enabled by editing the Web.config file for the vroot where the Web service resides. The following configuration enables both HTTP GET and HTTP POST:

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>

Alternatively, you can enable these protocols for all Web services on the computer by editing the <protocols> section in Machine.config. The following example enables HTTP GET, HTTP POST, and also SOAP and HTTP POST from localhost:

<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
<add name="HttpPostLocalhost"/>
<!-- Documentation enables the documentation/test pages -->
<add name="Documentation"/>
</protocols>"


Hi Fred,

wwIPStuff has nothing to do with .NET, so i very much doubt this has anything to do with a specific .NET version.

What are you doing exactly? wwIPstuff is very old and deprecated, and contains many features. There are newer classes that seperate out all that functionilty into separate classes.

The error you reference usually is caused by an invalid domain name in HttpConnect/FtpConnect.

+++ Rick ---


Apparently .net 1.1 disables httpget and httpget post (whereas .net 1.0 enabled them by default). I think this is .net 1.1, so the WC config file has somehow got to be changed to enable httpget and httppost.
How would I do this? and is this what would cause the 87 win32api error 'parameter is incorrect' to appear?
+++ Fred ---


Don't know then. This error is a generic WinInet error when an invalid parameter is passed into the API *or* the server returns an invalid HTTP response. Could also be related to network configuration (proxy/firewall) issues...

Unfortunately if that's what WinInet gives you for an error message there's not much more to check for. If you can debug, try stepping through the code and see which actual internal wwHttp code line is throwing the error.

+++ Rick ---


We have been using the exact same thing on our server for 5 years before going onto the cloud and never had a problem.
lcText=o.HttpGet("https://domainname.com/postbacks/backgroundcheck.aspx)

[domain name is the clients domain] where they have the aspx in a subdirectory.

Parameter is incorrect is usually an invalid domain name. Make sure you're using the right domain syntax not a URL. CHeck the docs.


+++ Rick ---


I had the client (who is not receiving the httpget postback) talk to the hosting company and this was the conclusion, either an error in the software preventing the data from going out or some configuration problem.
Like I mentioned before, the postback function does give a 87 win32 api: parameter is incorrect, so I think it is attempting to send it out but its not being recognized somehow.

> we captured packets on the server itself. They seen our
requests come in but your postback was never seen at the network card
level. What this means is the software is not sending the response
back out. It may be trying to, but there is an error within the
software that is preventing the data from going out.
The setup of West Wind must not be correct or there is some type of
configuration problem.<

Well that's a network configuration issue not something that has to be dealt with at the application level. You'd probably know if there was a problem with the adapter configuration because no outbound connections are going to work if that's the case.

+++ Rick ---


Is it possible that the following may be causing the problem,

>However, is it possible that you need to reconfigure this
tool to use the nic of your new virtual server. Is there a chance that
it was duplicated from the old server and is looking for a nic that
doesn't exist. Or is there some configuration file on your server that
was copied from the old server that needs to be edited for use on the
new server. <

Make sure your firewall allows your app to access port 80 (or whatever port you're accessing). Normally the error means the URL is incorrect, but it can also happen if the url cannot be reached due to blocking of a proxy/firewall etc.

+++ Rick ---



I moved to a cloud server with the same software (W2003 server, webconnect 4.66, VFP 9) - but I am getting a error 87 win32 API parameter is incorrect. The offending code seems to be in the httpget().

Only thing I know that is different in the cloud is,
that they have a DNS pointer going to the public IP address. The Mission Critical Cloud uses a NAT/MIP setup which you will receive a private IP address that is mapped to a public IP.


So in the cloud computers network settings the IP address is different than the public IP they assign to us.

Fred



























Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

© 1996-2024