Re: [OpenSTA-users] Can a script wait until the end of a HTTP Binaryfile download completes before continuing?

[Tam W. <tam...@te...>]

Hello Dan and Bernie and the list,

Thank you both for your quick responses.  I won't be back on this work
until Friday so will investigate more then and report back.  =20

The following is further info, but no need to respond to it unless
something obvious jumps out to someone.  First priority is for me to
retry it.  It will help a lot knowing that it should work.
=20
----------

I must be doing something different or not understanding something as my
code looks very like Bernie's example.  And I have tried with and
without SYNCHRONIZE REQUESTS and with and without LOAD RESPONSE_INFO.
However it is worth me repeating these tests as I was experimenting at
the time and might have got something wrong. =20

My file takes at least a few minutes to download manually vi IE (13Mb)
but in OpenSTA it is only reported as a few seconds. =20

I tried the LOAD RESPONSE_INFO only because I thought that way I could
see how much of the body I was getting.   I could only get (log) the
first 5 bytes of the file. But the 64Kbytes limitation might mean that I
was shooting myself in the foot with that idea.  I will try not using
the LOAD RESPONSE_INFO.  =20

Another idea... Perhaps it is because I have only tried it in the Run in
the Test Modeller and the Single Step in the Commander, OR not let the
test run for long enough for the full download to occur.  I see in the
single step log it says something like 'binary body' and implies it
won't therefore show it in the log.  I will try a full (not single step)
test run with code like Bernie's and run it for long enough for the full
file download to complete and check what value the timer returns.
=20
As you pointed out I don't really need to wait for the GET to finish, I
just want a timer value which is the download time (to the last byte of
the binary file) and more importantly I want the full body being
downloaded through the proxy I am testing (rather than the connection
being dropped) so that it experiences all that load.

I'll report back on Friday.  I appreciate your help.

Regards,
Tam



Bernie Velivis wrote:
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>The essense of what Dan said is correct ...