HTTP POST requests kill webserver

Dear community,

I am facing a very weird problem here.
We've got a webgui that we need to automatically configure and we've tried almost everything.. we're basically approaching this by sending HTTP POST requests. The webserver is a Allegro-Software-RomPager/4.01.
First, we manually filled out the form and send it. Thus, we were able to record the actual request with Firebug.
The post data is as following:
Next, we tried simulating that request with VBScript code:

Dim subConfigureUPSNM_objXMLHTTP	: Set subConfigureUPSNM_objXMLHTTP = CreateObject("MSXML2.XMLHTTP") "POST", subConfigureUPSNM_strAddress, False, "admin", "admin"
	subConfigureUPSNM_objXMLHTTP.setRequestHeader "Content-type", "application/x-www-form-urlencoded"
	subConfigureUPSNM_objXMLHTTP.setRequestHeader "Content-length", Len(subConfigureUPSNM_strParameters)
	subConfigureUPSNM_objXMLHTTP.setRequestHeader "Referer", subConfigureUPSNM_strReferer
	subConfigureUPSNM_objXMLHTTP.setRequestHeader "Connection", "keep-alive"
	subConfigureUPSNM_objXMLHTTP.setRequestHeader "Accept-Encoding", "gzip, deflate"
	subConfigureUPSNM_objXMLHTTP.setRequestHeader "Authorization", "Basic YWRtaW46YWRtaW4="
	subConfigureUPSNM_objXMLHTTP.send subConfigureUPSNM_strParameters
	Wscript.echo subConfigureUPSNM_objXMLHTTP.statusText

Open in new window

Sadly, this totally kills the webserver? When pinging it, it just says "Destination host unreachable" and "Request timed out". However, not all the time, only sometimes. (Analyzing the application layer traffic with wireshark, we were able to deduce, that the only difference is, that the HTTP 303 See Other package never turned up, when the webserver would crash. Through manual and sometimes when the scripted/automated method was successful, the HTTP 303 See Other package did show up.) After a while, it comes back up and the change we tried to send through the POST request didn't go through. Alright, we tried MSXML2.ServerXMLHTTP next. Same approach, just with timeouts. Again, webserver goes down sporadically. We looked very confused at this point.

Alright, time for some C# and Powershell. Maybe MSXML2.XMLHTTP and MSXML2.ServerXMLHTTP is just not working. Well, we were wrong ...

$tcpClient = New-Object System.Net.Sockets.TcpClient("", 80)
$stream = $tcpClient.GetStream()
$stream.Write($postRequest, 0, $postRequest.length)
$buffer = New-Object System.Byte[] 8192
$tcpClientCount = $stream.Read($buffer, 0, 8192)
write-host ([System.Text.Encoding]::ASCII.GetString($buffer, 0, $tcpClientCount)) -ForeGroundColor Red

Open in new window

That approach was also tried through basic telnet. However, both produced the same "errors" as the VBScript: sometimes the webserver would accept the changes (Although with http status codes 303 and 403, but the values were still posted) and sometimes he'd just totally go down.

Now up to C#. First WebRequest:

WebRequest req = WebRequest.Create("");
            req.Credentials = new NetworkCredential("admin", "admin");
            req.Headers.Add(HttpRequestHeader.Authorization, "Basic YWRtaW46YWtyb3BvbGlz");
            req.Method = "Post";
            req.ContentType = "application/x-www-form-urlencoded";
            Stream s = req.GetRequestStream();
            byte[] bytes = Encoding.ASCII.GetBytes("ManagerLogin=admin&NewPassword=newpw&ConfirmPassword=newpw&SecurityMode=1&Submit=+Save+");
            s.Write(bytes, 0, bytes.Length);
            StreamReader r = new StreamReader(req.GetResponse().GetResponseStream());

Open in new window

Second HttpWebRequest:

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("");
			req.AllowAutoRedirect = true;
			req.Credentials = new NetworkCredential("admin", "admin");
			req.Headers.Add(HttpRequestHeader.Authorization, "Basic YWRtaW46YWRtaW4=");
			req.Method = "POST";
			req.ContentType = "application/x-www-form-urlencoded";
			req.ContentLength = (System.Text.Encoding.ASCII.GetBytes("ManagerLogin=admin&NewPassword=newpw&ConfirmPassword=newpw&SecurityMode=1&Submit=+Save+")).Length;		
			Stream stream = req.GetRequestStream ();
			stream.Write(System.Text.Encoding.ASCII.GetBytes("ManagerLogin=admin&NewPassword=newpw&ConfirmPassword=newpw&SecurityMode=1&Submit=+Save+"), 0, (System.Text.Encoding.ASCII.GetBytes("ManagerLogin=admin&NewPassword=newpw&ConfirmPassword=newpw&SecurityMode=1&Submit=+Save+")).Length);
			StreamReader streamIn = new StreamReader(req.GetResponse().GetResponseStream());
			string response = streamIn.ReadToEnd();

Open in new window

Guess what? Yes! Same phenomenon. We're totally clueless. We're out of options and we need a solution. I'd be very happy if someone could take a look at this and give their professional opinion.

Thank you.
Who is Participating?
raiERBAuthor Commented:
I was able to figure out the problem with one of our senior software developers today. It appears, that the webserver requires a GET request before the actual POST request where all the data is being transfered. Well, I simply requested the page where the form was present through GET and after that I sent my POST and voilá, it works. Apparently it's got something to do with the basic authentication which the webserver has to work out.. anyways, problem solved! Thanks to anybody who had a look and was trying to figure it out, I hope if someone else faces a similar problem in the future they will try to use a GET request before their POST request first.
David Johnson, CD, MVPOwnerCommented:
This is a pretty specialized piece of hardware have you tried contacting their customer support
They are the best people to ask
raiERBAuthor Commented:
I've done that, however, seeing as I haven't gotten a reply with a workaround yet, I'd like to keep the question open for other experts to have a look.
raiERBAuthor Commented:
Problem solved by myself.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.