HTTP Debug not working

Opto_Will

Having a problem with HTTP Framework debugging.
There is a longer story here but the basics are that we refreshed a working HTTP Serving Dev Env with an updated user data set.
Now we can't trigger a debug where we used to be able to :(

We are running this from the command line (as we always have)
Java -jar OESocketServer.jar -l eserver.cfg -d 3

HTTP Framework Setup - API Server Settings
Debugger Setting is "Enabled" for "HTTP_DEBUGGER_SERVICE"

If we run a procedure with no debug it reponds fine with the expected response.
If we drop a 'debug' in that procedure we get a 502 - Bad Gateway reponse instead of the OI Debugg window popping like the good old days.

What am I doing wrong/forgeotten to check?

(I have tried my own Debug Intercept procedure just to see if it hits there but no dice...)

Opto_Will

I should note debugging works fine in OI itself.

{We had some issues in the past where that wasn't the case when there was a OI Licence file version mismatch with actual version of the OI Application running.}

Not the case here....

DonBakke

Just to be clear, are you trying to invoke the visual Debugger or are you trying to call the Debugger intercept routine? These are mutual exclusive options, but your posts introduce elements of both.

Opto_Will

Sorry @DonBakke, Visual Debugger.

That wasn't working so I changed the HTTP Framework setting to 'Intercept' and tried to use my own routine to see what I could catch. Unfortunately the fish weren't biting so I have since reverted this back to the defaults...

So for the purpose of this, just the standard debug window.

DonBakke

Thanks for the clarification. I do want to point out that the debugger intercept routine will not get called using a debug statement. It will only get called if you encounter a runtime error. Not sure you were aware of that.

When the API is getting called, does an engine show up in your task manager? If not, then this would explain why the debugger isn't appearing.

Opto_Will

Don,
I wasn't aware of that. Thanks for the calirifcation.

*whew*. You had me scared for a second. Yes, an engine spins up!
I had no other running instances of OI and did a call using Postman so I could clearly see the result of my request.

FYI I have already reinstalled the HTTP Framework, SRP Utilities etc. I also ensured we had no localised versions of the HTTP* procedures
(Once upon a time we had HTTP_ENTRY_POINT_SERVICES and HTTP_RESOURCE_SERVICES so I wanted to make sure that wasn't the case.)

DonBakke

I'd like you to try a couple of other experiments. First, call Msg() instead of debug in your code. I'm curious if that will appear on the desktop. Second, try putting a debug in HTTP_MCP right before and right after the code that sets the debugger configuration.

Opto_Will

The MSG() didn't trigger anything and the JSON was returned as expected.
This was the same behavior with the debug in the HTTP_MCP!!!

Getting concerned, I just triple checked the location of my Java -jar OESocketServer.jar -l eserver.cfg -d 3 call, as well as the location of the engine that got spun up wth the call (via Task Manager).
I am confident I am in the right environment!

Opto_Will

Sorry @DonBakke, forget everything I just said. It is a lie.
I didn't restart my OESocketServer before every attempt so I think I was getting some cached results. Rookie mistake.

So the ACTUAL answers to your requests:
MSG() does fire in my code. Debug does not.
Debug does not fire in HTTP_MCP. MSG() does

and, just to be clear,
Debug does fire in normal SRP Editor activities...

Opto_Will

And just to confirm my settings for my 4.0.9.7 install.

Opto_Will

To pre-empt, here is a (sanitised) log of the request with debug present in code. It returns a 502 Bad gateway.



Request Argument -------------------------------------------------------------------------------- <01> HTTPQueryString : <02> HTTPPathInfo : tiles/EmployeeInfo <03> HTTPContentType : <04> HTTPContentLength : 0 <05> HTTPGatewayInterface : CGI/1.1 <06> HTTPHTTPS : on <07> HTTPAccept : */* <08> HTTPCookie : <09> HTTPFrom : <10> HTTPReferer : <11> HTTPUserAgent : PostmanRuntime/7.28.3 <12> HTTPTranslated : C:\inetpub\wwwroot\tiles\EmployeeInfo <13> HTTPRemoteAddr : 192.168.10.7 <14> HTTPRemoteHost : 192.168.10.7 <15> HTTPRemoteIdent : <16> HTTPRemoteUser : <17> HTTPRequestMethod : GET <18> HTTPScriptName : /cgi-bin/oecgi4.exe <19> HTTPServerName : my.domain.com <20> HTTPServerPort : 443 <21> HTTPServerProtocol : HTTP/1.1 <22> HTTPServerSoftware : Microsoft-IIS/10.0 <23> HTTPServerURL : <24> HTTPNoURLDecode : <25> HTTPResponseIsBinary : <26> HTTPRegistrySettings + RegistryInfo : SOFTWARE\RevSoft\OECGI4 EngineName : ServerURL : localhost ServerPort : XXXX ApplicationName : OPTO UserName : XXXXX StartupFlags : 65 ShutdownFlags : 1 FilePath : FilePathMapped : FileMode : 1 SysDownPage : OILocation : AdditionalValues : HTTP_AUTHORIZATION,HTTP_X_AUTHORIZATION, HTTP_DEBUG,HTTP_MEDIA_TYPE,HTTP_ACCEPT_ENCODING,HTTP_ACCEPT_CHARSET,HTTP_ACCEPT_LANGUAGE <27> HTTPOECGIVersion : VERSION:OECGI4 <28> HTTPGetString : <29> HTTPPostString : <30> HTTPAdditionalValues + Authorization : Basic XXXX X-Authorization : -Debug : Media-Type : Accept-Encoding : gzip, deflate, br Accept-Charset : Accept-Language :

DonBakke

Thanks for the pre-emptive posts. I was going to ask for them. :)

So there is no response log? This would suggest that the engine is definitely failing to complete the request, which I'm certain is happening when the "debug" statement is getting called.

In the above request log post, I see "-Debug" instead of "Debug". Can you confirm that you have HTTP_DEBUG listed as an AdditionalValues setting in the Registry?

Opto_Will

Thought you might ;-)

No, No response log.

this is the full Registry for Additional Values.
HTTP_AUTHORIZATION,HTTP_X_AUTHORIZATION, HTTP_DEBUG,HTTP_MEDIA_TYPE,HTTP_ACCEPT_ENCODING,HTTP_ACCEPT_CHARSET,HTTP_ACCEPT_LANGUAGE

DonBakke

Please remove the extra space before HTTP_DEBUG. I can't see how that would cause the odd behavior, but it would certainly prevent you from using the Debug request header correctly. BTW, are you testing with Postman or similar?

Opto_Will

Space Removed.
No difference in either of the above tests.

I was originally using our WebApp with the Browser F12 Dev Tools yesterday but I honestly find it easier for testing to just to use Postman so that is what I am using :)

DonBakke

Pretty much what I expected. However, this will give us another experiment to try. Remove all debugs in your code. Then run the request using Postman but add "Debug" as one of the Request headers and put a 1 in the value for this header. Let me know what happens.

Opto_Will

OK. Hopefully this will be helpful.

Debugs removed.
Added "Debug" with a value of 1 in the Headers in the Postman request.

No change from the Postman side of things (still a 502 error).
However, it DID generate a 200 OK log entry that looks like it contans the JSON pack we want!

However, even then removing the DEBUG header in Postman keeps that same behavior (generates a OK log but doesn't show in Postman) until the engine is restarted.
Once restarted the same request is the processed OK.

DonBakke

Well I'm stumped. Restarting the engine server shouldn't make any difference because you aren't changing code when all you are doing is adding or removing the Debug header in Postman.

Opto_Will

You and me both!

I don't disagree with you about the restarting Don but experience has proven otherwise ;-)

I think I will bring that env back to my local and set it up to serve from scratch from there.
I will also test with a backup from a month or so ago.

See what happens.

Opto_Will

@DonBakke, I might have found something.

I think it might be related to the Startup flags we were discussing a month or 2 back. I had changed the Statup flag to 65 as you (or rather Bryan from Rev) noted.

Therein lies my problem somehow. I changed the flag back to 66 and my Debugs all of a sudden started to work. I am about to go through the matrix of 1/2, 65/66 and see whats what.

Question though, what is the difference in the startup flags in the OECGI registry entry and the eserver.cfg?

DonBakke

@Opto_Will - That's a great find. I would not have thought that 65 or 66 would have made any difference. That said, both 65 and 66 are not supposed to show the engine UI. Thus, when you previously told me that an engine is appearing on the desktop I didn't think to pursue this any further. 65/66 should only be the settings for a production environment whereas 1/2 should only be the settings for a development environment.

eserver.cfg, IIRC, provides the default settings. Different clients that use the OengineServer can have their own "override" settings. For instance, the BRW uses CFG_OIBRW. The OECGI uses the Registry.

BTW, I've been traveling since mid last week and will still be out until this weekend. Thus, I haven't been able to do any local testing since you originally brought up this issue. Please keep me advised of your test results.

Opto_Will

@DonBakke, that makes two of us! I thought the difference between 65/66 was whether or not it always spawned a new engine or used a current engine (of course, other rules apply as per our conversation with Mr Montoya ;-) ).

This is from the SRP wiki page for CFG_OIBRW. I referenced this because the OI documentation for OEngine didnt seem to really tell me what I wanted to know (with my 'Boys Look') and this seemed reasonable according to my understanding.
1 (or 65) Always create a new engine. This is the default value if this attribute is left empty. 1 = Show engine UI. 65 = Hide engine UI. 2 (or 66) Use the current engine if possible, else create a new one. 2 = Show engine UI. 66 = Hide engine UI.

What we wanted to do was to hide the engines in a Production environment (run as a service) but still trigger the OI debugger if the OEngine was run in debug mode (Java -jar OESocketServer.jar -l eserver.cfg -d 3) vi CLI.

I always wondered which Startup Flag would take priority, Eserver or Registry. I guess I thought it was the Eserver since we reference it in the actual command and are using the Ports etc. from there. However, my testing backs up your recollection about eserver.cfg being the default that will be overridden, in this case, by the OECGI4 values in the registry. Pretty much any startup flag EXCEPT 65 in the Registry triggers the OI Debug window!! I think that is weird and can't explain the logic but *shrug*.

Anyhoo, here were the results.
E.cfg Reg OI Debug work 66 66 Y 66 65 N 66 2 Y 66 1 Y 65 66 Y 65 65 N 65 2 Y 65 1 Y 2 66 Y 2 65 N 2 2 Y 2 1 Y 1 66 Y 1 65 N 1 2 Y 1 1 Y

I will have to have a think about what we want our standard Reg/CFG values to be for both Dev and Deploy environments. I might have been wrong in my reasoning to use it but 66 is looking good right about now!!

Thanks for your help Don. Enjoy the rest of your travelling :)

DonBakke

I will corroborate your results when I return. Then I will report to Revelation.

Opto_Will

Cheers Don.