|
Are you up to date on HTTPAPI version?
On Fri, Jun 5, 2020 at 10:47 AM K Crawford <kscx3ksc@xxxxxxxxx> wrote:
I have a program that is using http_url_get (it has been for several(20128))
years). It is now working sometimes (quick estimate is 60% of the time).
Note that it started acting up about a week after I put new PTF's
TR7 on. For that week it was working fine.Obviously
When I look at the return code of http_url_get the fails return -1. My
research tells me that it is an 'internal error' failure. When I look at
the http_error() it is empty.
When it is a successful run my target JSON file has good data. When it
fails it is empty.
I have talked to the service provider and everything looks good to them.
I turned on the http_debug in the program. I have been testing with the
same http_url_get statement. So the results should be the same.
the successful ones look good.identical
When I compare the logs of the fails to the successful. They are
(except for date/time stamps). When you get to the part where it has thelist
JSON stuff is where it is different.
This is a bad example of the log by where the data should be:
SetError() #13: HTTP/1.1 200 OK
recvresp(): end with 200
recvdoc parms: identity 70975
header_load_cookies() entered
recvdoc(): entered
SetError() #0:
recvdoc(): Receiving 70975 bytes.
http_close(): entered
Notice nothing between recvdoc() and http_close.
Two of my fails had 49142 char of the JSON line. The rest have no
line/data.
This is a successful example of the log by where the data should be: I
truncated the JSON line, it has all 70975 char.
SetError() #13: HTTP/1.1 200 OK
recvresp(): end with 200
recvdoc parms: identity 70975
header_load_cookies() entered
recvdoc(): entered
SetError() #0:
recvdoc(): Receiving 70975 bytes.
[{"nCount":"454895600","vcRecordId":"0004...
http_close(): entered
Note that this has the JSON between recvdoc() and http_close.
I have entered the http_url_get into my browser and always am successful.
Trying to figure out why the one line of the log file would be missing.
I know this email got long. Any thoughts would be appreciated.
Confused.
--
Kerwin Crawford
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx--
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
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.