We're attempting to set a timeout on HTTP requests by using the SET_TIMEOUT command. The documentation states that the -12 status means "An internal error occurred", which doesn't really lend any insight to what the issue might be.  What would cause this sort of error that would cause a timeout not to be set correctly, outside of an incorrect time format (which is a -13 status)?  Is there additional logging that I can put in place that would show me more detail or give me an indication of where to look next?

Having said that, is there a better way to make sure that a HTTP request doesn't run infinitely or using SET_TIMEOUT the right approach?

Hello Tim,

do you have a file "ca-bundle.crt" in ...\\common\\usys?

If not you can use SET_FLAGS.

See Docu : https://docs.rocketsoftware.com/bundle/uniface_104/page/kbj1665702546119.html

Regards 

Norbert

Im currently using value 4 and 2 when I call SET_FLAGS.  Which value would I use in relation to a timeout.  I see that 16 allows HTTP requests to be sent individually.But I dont understand how SET_FLAGS relates to configuring a timeout.

Hi

You use the SET_TIMEOUT(milliseconds) operation to set a timeout, -1 to wait indefinitely.

Passing 2 to SET_FLAGS() permits to avoid client certificate checks (which could be an error).

Usually -12 means "host unreachable", which could mean a lot of things, but at a glance, the HTTP client cannot reach the HTTP server (wrong URL, proxy limit, server down, etc..)

Regards

------------------------------
Richard Gill
Dedalus Healthcare France
Artigues Pres Bordeaux FR
------------------------------

I know -12 during the SEND is generally an issue with the host in some way.  But my assumption is that if you execute SET_TIMEOUT before the send, the control doesnt actually communicate with the host.  Basically what Ive done is initialized a new instance of the UHTTP control, SET_FLAGS, SET_TIMEOUT, then SEND.

Since the UHTTP control wouldnt be communicating with the host until the SEND (If Im understanding correctly), then what else would -12 be?  Or is there a way to turn on some logging either in Uniface or otherwise, that would give me more info.

Hi Tim,

did you read the docu?

Can you show your code with SET_FLAGS?

I did read through the documentation.  Which is why I asked about how that relates to setting a timeout.  Perhaps Im misunderstanding what I should be seeing in the document that isnt obvious to me.  Right now, I have SET_FLAGS set to 6, the combination of 4 and 2.  However, in reading through the options for 16, maybe I need to consider using that option as well?  Thats what was unclear.  Am I changing SET_FLAGS to include option 16, so I get more information or am I setting a flag to configure a timeout?

Do you have the file I mentioned?

What about FLAG 1? 

So setting SET_FLAGS(7).

We opted to use SET_FLAGS so we wouldnt have to generate that file for every customer of ours who uses the software.

Having said that, I dont have option 1 included, but I could see how that might be useful.  The interesting part about the issue that we're having is that we dont experience a problem all the time.  Its an intermittent problem, which Im mostly sure is an issue with the host, but I do not have enough information to be sure. When the issue manifests itself, the http request just sits there and runs indefinitely (until we manually kill the process).  What I want to be able to do is have the request time out after 5 minutes - regardless of where the request is in the process.  Generally the requests to this host complete and send a response within the first minute, so  5 minutes should be more than enough time to wait.    My thinking was that if I performed a SET_TIMEOUT of 300000 milliseconds (5 minutes), then it would time out.  However, when I run a proc trace, the last line of code to be executed is the uhttp.send, which Im guessing is that its waiting for a response.

I hope that makes sense.  I think including option 1 (SET_FLAGS(7)) is probably a good move to reduce the inevitability of an issue.

Im open to options for logging.  I know there's an ability to turn on some UHTTP proc tracing, which generates a curl_debug file.  The only issue with that is the curl_debug file gets overwritten after each execution and we cant re-create the issue at will.  So we would need a history of curl_debug files to be useful in tracing the issue.

I appreciate all the help so far.

With 

[SETTINGS]

$trc_start uhttp.log 
$trc_levels 9U

you can trace UHTTP. Maybe this helps?

Yep.  Those are the settings that generate the curl_debug.txt file separately when you set the $trc_levels to 9U.  The issue is that while the tracing shows up in the uhttp.log (using your example), the output of the curl_debug.txt file does not.  And it gets overwritten each time you execute - hence my problem. 

The curl_debug.txt is the valuable part of the equation because it shows the transmission between the program and the host.

One possibility is to maybe try to copy the file somewhere else, maybe at the end of the HTTP request, so I dont lose the data.  That would solve that issue.

We're attempting to set a timeout on HTTP requests by using the SET_TIMEOUT command. The documentation states that the -12 status means "An internal error occurred", which doesn't really lend any insight to what the issue might be.  What would cause this sort of error that would cause a timeout not to be set correctly, outside of an incorrect time format (which is a -13 status)?  Is there additional logging that I can put in place that would show me more detail or give me an indication of where to look next?

Having said that, is there a better way to make sure that a HTTP request doesn't run infinitely or using SET_TIMEOUT the right approach?

Hi Tim,

In 10.3.03-015 and 10.4.01-015, the UHTTP component was extended with a GET_LAST_ERROR function to help diagnose the issue when -12 is returned. It may give you some more information.

Kind regards,

Mike