Getting a response from a Perl script 2

[audiopro]

I have a VFP6 app which uploads a file onto a remote server, processes the contents of the file and populates a MySQL database with the contents. That is all working fine but I want to pass some information back from the server to the calling VFP6 application. Is there an API for this or is there a much simpler approach? I am just looking for a bit of guidance on this.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Ouch, that line somehow sneaked into the code, sorry. Simply remove it. loRequest has no OpenURL method, instead you use the combination of open to prepare and send to send a request. Between open and send you can do lots more stuff, set headers etc.

For VFP6 this should work:

loRequest = Createobject('MSXML2.XMLHTTP.6.0') && use 3.0 istead of 6.0 if your Windows version doesn't have MSXML6
loRequest.Open("GET", "[URL unfurl="true"]http://www.mysite.co.uk/cgi-bin/httpreq.pl",[/URL] .T.)
loRequest.Send(.NULL.)
DO WHILE loRequest.ReadyState # 4
DOEVENTS
ENDDO

Bye, Olaf.

 

[Olaf Doschke]

Oh, and after ENDDO the result of the request will be in loRequest.ResponseText

Bye, Olaf.

 

[audiopro]

Thanks Olaf, I am on with something else today so it will probably be Monday before I get into it.

Keith

http://www.studiosoft.co.uk

 

[audiopro]

The MSX method works except that some functionality within the Perl script is prevented from working.
Part of the functionality of the Perl script is to create a number of directories on the remote server.
Using the oinet method, the directories are created and files can be uploaded but using the MSX method, the directories are not created so the files cannot be uploaded to them. I am sticking with the oinet method for now as I need to get this up and running within the next few days.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

I am sticking with the oinet method for now as I need to get this up and running within the next few days.

I had the impression that you had got it working in your production environment some days ago. Was there any particular reason why you went down the MSXML road instead?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[audiopro]

I got the occasional error Mile so I thought I would see if the alternative method would work. The way I have done it, the 2 bits of code are fairly interchangeable. Well they would be if they both worked but I am sure you know what I mean.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Yes, I know exactly what you mean, Keith. Even if you don't get any errors in production, it would be nice to know why they occurred in the dev. env.

By the way, did you ever try my suggestion of doing a Wait Timeout for a few milliseconds after the call to OpenURL? I'm not insisting that it would necessarily work, but it would be good to know one way or the other, if only for future reference.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

How could directory creation ever be related to MSXML2.XMLHTTP.6.0 vs inetctls.inet?
These two classes just make a http request, they don't do anything else, no directory generation. Try a simpler URL and see if the request comes through.

Bye, Olaf.

 

[audiopro]

Made no difference Mike, I put some quite long timeouts within the code and the error still occurred. That only seems to happen in the dev environment.

Keith

http://www.studiosoft.co.uk

 

[audiopro]

I quite agree Olaf, it sounds odd but that is what is happening.
I have run both options many times and I get the same result every time and the Perl script is never changed.




Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

I put some quite long timeouts within the code and the error still occurred.

OK. Thanks for checking.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[audiopro]

Then the machine crashes and after a restart all is well again.
I think I may stop working with computers and get myself an allotment, how difficult can it be to get rid of a bit of carrot fly?

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, the two classes may send different request headers (in short: there is more to a http request than the URL requested and the method used, like GET or POST) and your web server may cope better with what comes from inetctls.inet.

Then that's it, using MSXML2.XMLHTTP was merely an attempt to get around the inetctls.inet error "Still executing last request". You don't have that error anymore?

Bye, Olaf.

 

[audiopro]

I am keeping an open mind until I carry out further testing but it is at least working in part thanks to your assistance..


Keith

http://www.studiosoft.co.uk

 

[audiopro]

My VFP app does the HTTP request to the perl script, the perl script checks for the existence of a number of files on the server. If all the files are present, the string 'G11111111111' is returned. Each '1' represents the presence of a particular file. If that file is missing, the 1 is replaced with an error code.
Back in the VFP app, the returned value is checked and if the value is 'G11111111111', then all is well and the process can proceed, if not then the upload section of the app is run again.
I ran the vfp app and I got the correct check string back and left the VFP app running. As a test, I deleted one of the files from the server (via FTP client) and ran the upload section again. I got the success string back even though there is a file missing.
Running the perl script from the browser, returns the expected string containing the error code.

It would seem that the object is still active and is returning the previous error code.

Is there a way to destroy the MSX object once a value has been returned?


Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

MSX is something completely different, but I know what you mean.

That aside, it makes use of caching configuration of windows, so let perl add a header signaliing no cahcing, and everything would work with "MSX", too.

To be more precise, perl should add respond with a haeder
Cache-Control: no-cache

In Perl you can use the CGI object for that matter:

my $query = new CGI;
print $query->header(-cache_control => 'no-cache');

You can see, if that header arrives at MSX via ? loRequest.GetAllREsponseHeaders() in VFP.
In your earlier code you simply printed the header text
print "Content-type: text/html\n\n";

You may modify that to print both headers:
print "Content-type: text/html\n";
print "Cache-control: no-cache\n\n";

Only the last header is seperated by a double \n, otherwise further "headers" become part of the html body, and even if you don't send real html, but just such a string 'G11111111111', http works this way and as a perl expert you should know a bit of that. You can again check, whether the headers arrive as such and effect the system to not cache your request.

Another solution would be to add a non used parameter with a random value and request ...yourscript.pl?dummy=dafhjkdkf, varying that parameter with each call, not using it in perl. SYS(2015) would be good to use for that. That will make it all different requests, which results won't be fetched from cache, even if you fail to suppress caching for whatever prioritized rule or policy of the system, both on client and webserver side.

Bye, Olaf.

 

[audiopro]

Thanks Olaf, I was forgetting about windows caching, always looking for complicated solutions when a simple one will do. I have used both methods - added the no cache header and the random var in the request string. I wonder if caching was the cause of the initioal problem in the oinet version?

Not so sure about the Perl expert tag though.
I use it as I prefer it to PHP but I only scratch the surface of it really.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, for example if the "Still executing last request" error comes from a hanging cache, but I doubt that.

Anyway, using http you go through a technology stack of windows internet components like winsock, proxy, cache, you go through your ISP to the webserver and finally into the scripting language used, and a request may hang in any of the perticipating modules.The stack is smaller, if you run a webserver local, then the ISP part is out of the play, still enough modules in that stack.

Lately I spent an hour finding out a URL rewrite rule in config.web of IIS causes a POST request to become a GET request, as it's redirected and therefore the caller get's a response making hinm repeat a request to the new URL, which had parameters.

Even though I configured a temporary redirect (respoinse status 307), which by some sources means the browser (or MSXML.httprequest) should repeat a request to the redirect URL including the request type and associated data, it did not. And if you look further, you read this should work that way, but only works with some and not other browsers (or MSXML2.XMLHTTP or Inetctls.Inet).

So, there are frequently new pitfalls in this technology stack. It's all very simple, isn't it? It's man made, it's not nature, man made it and all the rules, and he could do it as simple as he could do it. Like language, or politics, or relationships.

Bye, Olaf.

 

[audiopro]

Nothing in the world of computers appears to be done using the simple, straight forward option. It is as if, simple just isn't good enough and a really large, complex and badly written method is always the designer's preference over something simple.
The app I am writing is not being wheeled out anywhere, it is for my own use and will simplify a regular, tedious task I have to perform.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, yes, that was sarcasm, you got it.

Wish you good luck with further tasks.

Bye, Olaf.