View Full Version : Receiving STDIN
If I have a script that is going to receive an xml feed sent via a http post how do I access the data which I believe comes in over stdin? The documentation (v3.96)says that I can't directly access stdin. If I need to go to ver 5.x I have it installed, but the question is still the same.
Thanks,
Donb
aGorilla
05-24-06, 08:11 PM
Built-In System Variables (http://smallbusiness.miva.com/support/docs/ScriptGuide_html/ScriptGuide.html#495201)
argN
If a list of values is passed to a MIVA Script program, argN is the value of the Nth argument on the URL used to call the script. arg1 always contains the program file name. The first argument after the file name will be arg2, and so forth.
EDIT: when using it, you should scope it as a system variable with 's.' eg: s.arg1, s.arg2, etc.
It's not passed as an argument. It is sent in a post as a data stream to stdin. Those are not in the argn varaiables. At least not that I can see.
Kent Multer
05-24-06, 09:40 PM
I don't think Miva scripts can receive raw data like that. You need to at least prefix your XML text with a name, such as "xml=," or else repackage it so that it looks like an uploaded file. Then the data shows up just like a regular form submission, which Miva can process.
I have got this down to where I can succesfully receive a post from say an MvCall. The below listed code is all that is really needed. The problem is that I must know the name of the var that the data was sent in.
<MvASSIGN NAME="datasize" VALUE="{ content_length }">
<MvASSIGN NAME="datatype" VALUE="{ content_type }">
<MvEXPORT FILE ="{OutFileName1}" FIELDS = "datasize,datatype,strXMLResponse" DELIMITER = "||">
When the vendor trys to run his program to post the data he is receiving back an error 500. The snippet of code that actually post is:
if (strXMLResponse.length() > 10)
{
httpConnection = new HTTPConnection(new URL (server));
// httpConnection.setDefaultHeaders(headers);
rsp = httpConnection.Post(server, strXMLResponse, headers);
System.out.println("rsp content type = " + rsp.getHeader("Content-Type"));
printout.writeBytes(strXMLResponse);
}
printout.flush ();
Any Ideas as to what I might do or should I give up and go to perl or some other language?
Kent Multer
05-26-06, 09:50 PM
What part of my previous message did you not understand :^) ?
Testing with MvCALL is not useful, because the FIELDS parameter gives names to the data that it posts. The vendor's code snippet apparently sends raw XML data with no name, so the receiving Miva script has no way to access it. There's nothing you can do in Miva to fix this; the vendor needs to change his code to make the data look like a normal form submission.
truXoft
05-27-06, 09:25 PM
As for HTTP or HTTPS data transfers (regardless if XML, HTML, plain-text or binary), you can do practically whatever you want with pure Miva Script. I have yet to see an application that would not manageable by MvCALL. Sometimes it requires little bit of trickery, but there is always a way. The easiest way to develop such application is using a TCP/IP packet sniffer and monitoring the content of the transmitted packets both with Miva Script and with another application that is known to work in the given situation. In this way I always found a solution for many sites that initially posed problems.
It is difficult to give you some straight answer though - the situation may greatly vary depending on many factors, so as I wrote, you best study the HTTP protocol, use the TCP/IP packet sniffer, and simulate then the transfer schema with MvCALL.
Kent Multer
05-28-06, 12:10 AM
Ivo, I think you know more about Miva programming than anyone else on the universe, so forgive me for disagreeing with you ... MvCalls can send XML, but I don't think there's a way for a Miva script to receive an XML-type HTTP request. If the data passed to a script is not in the name=value format, then there's no way for the script to reference it -- or is there some system variable that can be used for this?
Thanks --
vBulletin® v3.7.4, Copyright ©2000-2008, Jelsoft Enterprises Ltd.