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?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
raiERBAuthor Commented:
Problem solved by myself.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
HTTP Protocol

From novice to tech pro — start learning today.