So Close!!

[Charabis]

For those following the saga, it’s nearly at an end After they checked the IIS log files they found my communication were coming over port 80, not 443. Simple fix right? Just add “:443” to the end of the address. Well, not really as this partial address shows from their logs:

SPS.svc:443 80

It looks like it’s determined to send it on port 80 and automatically tacks it onto the end. I’m using a straight WebRequest now, and just need to know how to get rid of that trailing " 80" that it wants to add for some odd reason. I’ve yet to find any mention in any of the documentation about this behavior. Thanks in advance.

[KelsoMRK]

Setting the port in HttpWebRequest.Create() doesn’t work?

[Charabis]

Using a straight WebRequest, not the HTTP version as shown below:

public string SendData(byte[ ] dataToSend)
{
WebRequest request = WebRequest.Create(soap.SoapUrl);

request.Method = “POST”;
request.ContentLength = dataToSend.Length;

Stream dataStream = request.GetRequestStream();
dataStream.Write(dataToSend, 0, dataToSend.Length);
dataStream.Close();

WebResponse response = request.GetResponse();

string output = “”;
using(StreamReader sr = new StreamReader(response.GetResponseStream()))
{
output += sr.ReadToEnd();
}

Debug.Log(output);
return output;
}

[KelsoMRK]

Is soap.SoapUrl a string? Maybe try backdooring a URI instead of a string?

This code is super ugly:

Uri u = new Uri(soap.SoapUrl);
UriBuilder ub = new UriBuilder(u);
ub.Port = 443;
u = ub.Uri;

WebRequest request = new WebRequest(u);

[Charabis]

Yes, it’s a string. I’ll try your suggestion and post the results in a moment.

Results are odd:

public string SendData(byte[ ] dataToSend)
{
Uri u = new Uri(soap.SoapUrl);
UriBuilder ub = new UriBuilder(u);
ub.Port = 443;
u = ub.Uri;

WebRequest request = new WebRequest(u);

// WebRequest request = WebRequest.Create(soap.SoapUrl);

request.Method = “POST”;
request.ContentLength = dataToSend.Length;

Stream dataStream = request.GetRequestStream();
dataStream.Write(dataToSend, 0, dataToSend.Length);
dataStream.Close();

WebResponse response = request.GetResponse();

string output = “”;
using(StreamReader sr = new StreamReader(response.GetResponseStream()))
{
output += sr.ReadToEnd();
}

Debug.Log(output);
return output;
}

Assets/SoapObject/GuiScript.cs(404,55): error CS0144: Cannot create an instance of the abstract class or interface `System.Net.WebRequest’

If I duplicate the previous call and try to use .Create, it says there’s no such method in the class. Weirdness %)

[Charabis]

I was just thinking, could it be something to do with running 3.3 on a Mac? They want it done in 3.3 and I’ve seen a number of discussions about using HTTPWebRequest, but it doesn’t seem to be supported in 3.3, at least not in System.Net where it’s expected.

For that matter if anyone can determine where the " 80" is coming from that would be a huge help. As it is, I can’t determine where that’s being added. As I see it, there are two end results that could work

1. Kill the " 80"
2. Substitute " 443" for the " 80" and remove the “:443”

The example of a properly formed request I was sent (The key part anyway)

/API/SPS.svc 443 -

What the server is showing I’m sending

/API/SPS.svc:443 80 -

Using this code:

public string SendData(byte[ ] dataToSend)
{
WebRequest request = WebRequest.Create(soap.SoapUrl);

request.Method = “POST”;
request.ContentLength = dataToSend.Length;

Stream dataStream = request.GetRequestStream();
dataStream.Write(dataToSend, 0, dataToSend.Length);
dataStream.Close();

WebResponse response = request.GetResponse();

string output = “”;
using(StreamReader sr = new StreamReader(response.GetResponseStream()))
{
output += sr.ReadToEnd();
}

Debug.Log(output);
return output;
}

[KelsoMRK]

WebRequest typically shouldn’t be instantiated via a constructor, hence the Create() method. Perhaps Mono is missing the Create overload that takes a Uri object? What is the value of soap.SoapUrl?

[Charabis]

http://protectpaytest.propay.com/API/SPS.svc:443 stored as a string. That trailing 80 is just odd to me. Could it be that there’s an issue in the parsing causing it to miss the port number entirely so it simply adds the default 80 to it?

[KelsoMRK]

Shouldn’t it be “http://protectpaytest.propay.com:443/API/SPS.svc” ?

[Charabis]

Heh. True that Oddly, correcting it results in it timing out with nothing showing in HTTPScoop as being sent out.

Interesting. If I drop that address (http://protectpaytest.propay.com:443/API/SPS.svc) into a web browser, it also doesn’t register anything in HTTPScoop.

[KelsoMRK]

I’m an idiot…443 is the default https port.

Perhaps “SPS Service” would work better.

We WILL figure this out, because I’m just annoyed at it now.

[Charabis]

Ditto here. On a Mac so couldn’t use scvutil to just generate their functions, so had to do the soap envelope manually. That works flawlessly, it’s just getting it to play nice with their server.

Well that change gives:

WebException: The remote server returned an error: (415) Cannot process the message because the content type ‘application/octet-stream’ was not the expected type ‘text/xml; charset=utf-8’…
System.Net.HttpWebRequest.CheckFinalStatus (System.Net.WebAsyncResult result)
System.Net.HttpWebRequest.SetResponseData (System.Net.WebConnectionData data)

Changing the type yields

WebException: The remote server returned an error: (500) Internal Server Error.
System.Net.HttpWebRequest.CheckFinalStatus (System.Net.WebAsyncResult result)
System.Net.HttpWebRequest.SetResponseData (System.Net.WebConnectionData data)

Sounds like it’s time to call them again Just odd it would work that way since the address they provided is the http, not https. Go fig

[Charabis]

Wow. On further experimentation, changing it to https results in nothing showing up on HTTPScoop as having been sent out.

[KelsoMRK]

HTTPScoop needs some fiddling to capture SSL packets.

http://www.tuffcode.com/support.html#support7

[Charabis]

Ah. So the requests are probably going out, but it’s not spotting them. That’s good news at least, although it does mean that I’m going to have to wait for them to call back to find out what’s happening on their end in terms of the data. I really hate not having direct access to the data I need

[KelsoMRK]

If you’re getting error 500 back then it’s definitely going out to their server. It could be an SSL certificate issue, in which case a workaround such as this might be your ticket.

[Charabis]

public bool AcceptAllCertifications(object sender, System.Security.Cryptography.X509Certificates.X509Certificate certification,
System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors)
{
return true;
}

public void Awake()
{
ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(AcceptAllCertifications);
}

After adding above code, I’m still getting the 500 error. Shame too since I was really hoping that would solve it. Getting tired of this section of code >.<

[Charabis]

According to the tech, the important part of the call is still coming in as

“POST /API/SPS.svc:443 80”

So let’s try a different approach. Here’s the code as it now stands in all its troublesome glory

public string SendData(byte[ ] dataToSend)
{
// Alternate way attempted which seems to yield the same results as “SPS Service”
/*
Uri u = new Uri(“SPS Service”);
UriBuilder ub = new UriBuilder(u);
ub.Port = 443;
u = ub.Uri;

WebRequest request = WebRequest.Create(u);
*/

WebRequest request = WebRequest.Create(“http://protectpaytest.propay.com:443/API/SPS.svc”);
request.Method = “POST”;
request.ContentLength = dataToSend.Length;
request.ContentType = “text/xml”;

Stream dataStream = request.GetRequestStream();
dataStream.Write(dataToSend, 0, dataToSend.Length);
WebResponse response = request.GetResponse();

string output = “”;
using(StreamReader sr = new StreamReader(response.GetResponseStream()))
{
output += sr.ReadToEnd();
}

return output;
}

If there’s no way to get rid of that trailing 80 it wants to keep adding under the Unitron editor with Unity 3.3 and WebRequest, what’s an alternative that will work? I’ve already attempted to use an HTTPWebRequest, but even with System.Net included, Unity declares it to be unknown.

[Charabis]

Solved It just needed a key/value pair in the header for the “SOAP Action”