× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sorry, I was just answering the last question about AJAX and didn't read back for the real question. Ajax is between your browser and your web server and it does all the XMLHttpRequest stuff. Your real question is about CGI. CGI is between your program and the web server. It is implied in the IBM documentation that STDOUT is handled as a whole when the main program called by the web server finishes. I don't think I've ever seen that stated definitively however. We decided against CGI for various reasons a good while ago, so I haven't dug into current versions of the documentation to see if anything has changed.




Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of
Henrik Rützou
Sent: Monday, February 20, 2017 12:09 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] QtmhWrStout

Call it what you want ;-)

I have a CGI-program that writes a buffer out via qtmhWrStout, i may call
qtmhWrStout one or several times for the same transaction and it still works.
There is no way to signal to QtmhWrStout that the last call is the last call so
there is no way the HTTP header knows the length of the data that follows.

Since qtmhWrStout dosn't know when the stream end my program isn't
ending (*lr = on) there is no way Apache can know when data tream ends.

The whole transaction takes about 1.5ms in the cgi program running an SQL
and generating a JSON object.

I can btw build in a delay of 50ms between calls to qtmhWrStout it dosn't
matter if the CGI program runs for 151.1ms instead of 1.5ms the time in the
other end just takes around 180ms.

When I call it from my browser the entire call takes around 35ms so about
33ms is lost in transfering the about 4K of data somewhere.

If I do the same from a node.js program running in the machine calling the
service over port 127.0.0.1 where there are no network latency it takes
excactly the same time - 35ms so somewhere 33ms is lost in unaccouted
time.


On Mon, Feb 20, 2017 at 4:36 PM, Kevin Bucknum
<Kevin@xxxxxxxxxxxxxxxxxxx>
wrote:

What we call ajax is actually an XMLHttpRequest. There are messages
that set different states. Along with the states it sends byte counts
for various stages of the process. When it gets to the state that
indicates that it's done, it checks the bytes received against what it
was told to expect, and if it matches, starts processing the response.
https://xhr.spec.whatwg.org/





Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of
Henrik Rützou
Sent: Saturday, February 18, 2017 2:15 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] QtmhWrStout

Tanks,

but how does AJAX call know when e.g. a JSON file send is finish so
the
AJAX
starts to process the data it receives?

On Sat, Feb 18, 2017 at 9:03 AM, Stefan Tageson
<Stefan.Tageson@xxxxxxxx>
wrote:

since you may call QtmhWrStout repeatly to flush the total data
to a
browser through StdOut how do you tell it that it is *EOD so it
close the connection?

Hi Henrik,

As the browser established the connection, it will be in charge
for closing it as well. If your server does not reply in due time
then a timeout will occur.
Normally the browser "knows" when to close the connection based on
the data you sent.

Best regards

stefan.tageson@xxxxxxxx
M +46 732 369934


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/web400.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.