More - Post Command Problem looks like a RunRev problem?

[Mark Smith]

Dave, you'll need something like this:

put the tempname into tFile
put mySoapEnvelope into url("file:" & tFile) -- this is so we don't  
pass a load of data on the command line
put "curl -s" into tCurlStr

repeat for each line L in myHttpHeaders -- if you're only setting one  
header, you don't need a repeat, of course.
   put " -H" && "'" & L & "'" after tCurlStr
end repeat

put " -d" && tFile && tUrl after tCurlStr
put shell(tCurlStr) into tResponse
delete file tFile -- cleanup


If you want to see the whole exchange including headers and  
everything, then replace "-s" with "-v" in the third line.

Alternatively, you could try my library (http://futsoft.futilism.com/ 
revolutionstuff.html),
in which case it would be

put curl.new() into tCurl
curl.setUrl tCurl, tUrl
curl.setHeaders  tCurl, myHttpHeaders
curl.setPostData tCurl, mySoapEnvelope
put curl.runTilDone(tCurl) into tResponse


Best,

Mark


On 17 Nov 2008, at 14:40, Dave wrote:

> Hi Mark,
>
> I can't figure out the correct format for the "curl" command, or  
> how to call it from RunRev.
>
> Given that the current post command looks like this:
>
> set the httpHeaders to myHTTPHeader
> post mySoapEnvelope to url mySoapURL
> put it into myReply
> put the result into myResult
>
> How would I do this using curl? The function to send the command is  
> called from all over the place so I would have to change it in the  
> low level function, if so then the above is the only data I can get  
> at and I have to return myReply and myResult in the same format as  
> the post command would use.
>
> Is this possible using curl?
>
> Thanks a lot
> All the Best
> Dave
>
> On 17 Nov 2008, at 12:00, Mark Smith wrote:
>
>> Dave, I wonder if it would be worth trying to do the post using  
>> curl (or some other tool) to see if the problem still occurs?
>>
>> Also, have you looked at what actual bytes the truncated response  
>> ends with ie. is the server sending back something weird?
>>
>> Best,
>>
>> Mark
>>
>> On 17 Nov 2008, at 11:29, Dave wrote:
>>
>>> Hi All,
>>>
>>> Please see below for the history of this problem. Since then I  
>>> have some more information:
>>>
>>> I installed WireShark and recreated the problem. When I look at  
>>> the captured information, it looks as if the response is being  
>>> sent and received by server/client ok. It shows a number of TCP  
>>> packets (TCP Segment of a reassembled PDU) and then one block  
>>> that shows as HTTP/XML. When I select this block it shows the  
>>> packet reassembled as 23782 bytes. However when the error occurs,  
>>> the response return by the RunRev post command only shows the  
>>> first 2736 bytes, e.g. the rest of the reassembled block is  
>>> truncated. I have the dumps as text files but they are too big to  
>>> post here.
>>>
>>> When I looked up the post command in RunRev it says it is part of  
>>> the internet library, however I can't find any source code for  
>>> this. Is it available? I'd like to add some trace information so  
>>> I can see if this library is being passed the whole block and if  
>>> so why is it going wrong on this block.
>>>
>>> Is there another way to do this in RunRev? e.g. A alternative to  
>>> the "post" command?
>>>
>>> Any ideas or suggestions on how to fix or even get a handle of  
>>> this problem would be greatly appreciated.
>>>
>>> All the Best
>>> Dave
>>>
>>> ------
>>>
>>> I read records from a database, format them, and add them to a  
>>> block of data. There is a blocking factor variable, it is set to  
>>> 200, so I read 200 records from the database, block them into one  
>>> big block and send it to the server via a "post" command. The  
>>> Server then sends a response which can be variable in length, the  
>>> response is in XML format. This process works well 99% of the  
>>> time, but sometimes, (and this can be reproduced if the right  
>>> data (or the wrong data in this case!) is present in the  
>>> database). When this happens the response from the server is  
>>> truncated in the middle of an XML node. As far as I can tell the  
>>> difference is that by chance, a group of 200 records has caused  
>>> the response to be over a certain size.
>>>
>>> If I set the BlockingFactor to 50, the problem goes away, but  
>>> this causes a major slowdown.
>>>
>>> ------
>>>
>>> It is sending one block at a time, each block contains N records.  
>>> There are around 10,500 records in the database.
>>>
>>> Each record has an XML node in the reply, depending on the  
>>> content of the record sent, it will return different data of  
>>> variable size. It appears if the block returned is greater than a  
>>> certain size, it is truncated.
>>>
>>> Basically the process is:
>>>
>>> repeat for all Records in Database
>>> Read Record From Database
>>> Encode as XML
>>> Add to end of SendDataBlock
>>>
>>> if the number of records in SendDataBloack > SendBlockingFactor then
>>>   post SendDataBlock
>>>   get response
>>>   process response
>>>   put empty into SendDataBlock
>>> end if
>>>
>>> end repeat
>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution