Response for a debugger crash

MattCrozier

Is there an equivalent to the INET_ABORTED routine in the HTTP framework? I'm not sure how OpenInsight does it, but it seems its INET Gateway (RUN_OECGI_REQUEST?) is able to detect a break to debugger and still return a valid HTTP response.

My setup could be wrong but the response I get in this situation with the HTTP framework is

HTTP Error 502.2 - Bad Gateway
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are "1".

Cheers, M@

DonBakke

Matt,

Congratulations. You win today's award for helping me to learn something new. I was aware of INET_ABORTED, but others at SRP did the traditional INET-based OECGI work so I sort of ignored it. Your question prompted me to investigate this further.

So, through a little trial-and-error, I came to the conclusion that the nominated listener (normally RUN_OECGI_REQUEST, but HTTP_MCP for our purposes) will automatically get called when an error condition like this occurs. This is the purpose of the ProcErr argument. I knew what the argument was there for, but I had assumed it was only valid for RUN_OECGI_REQUEST. Thus, the description of this argument in HTTP_MCP reads as follows:

ProcErr [out] -- N/A. This is used by RUN_OECGI_REQUEST but left here since all listeners need two arguments.

This description is incorrect for two reasons. First, ProcErr is an incoming rather than an outgoing argument. Second, it is not limited to RUN_OECGI_REQUEST. I created a VNAV error in my Contacts service and this is what came through in my ProcErr argument:

ENG0010: HTTP_CONTACTS_SERVICES, line 45. Variable has not been assigned a value.ENG0010: HTTP_CONTACTS_SERVICES, line 45. Variable has not been assigned a value.

So...the answer to your question is "No, we do not have an equivalent to INET_ABORTED." However, the good news is that this is very easy to implement now that we understand how this operates.

I will definitely update the SRP HTTP Framework to handle ProcErr values. The question is what would be the best way to do this? There are some options and I would value your input (as well as others who are using the product):

1. Modify HTTP_MCP to check for a value in this argument, gosub to a label that formats the response but otherwise bypasses the normal logic that calls the services. In other words, this does what INET_ABORTED does but doesn't call out to another routine.
   
2. Do the same thing as identified above, but instead of routing to a gosub label, call a dedicated service routine that is the equivalent to INET_ABORTED.
   
3. Do the same thing as identified above, but instead of calling a dedicated service routine, it gets the name of the procedure from the SRP_HTTP_FRAMEWORK_SETUP configuration record.
   

I'm inclined to go with option #3, even though it might be more than anybody would care about. However, I already allow the developer to customize the entry point service so I might as well allow the developer to customize the abort service as well.

MattCrozier

Hi Don,

Great! - I'll take that award as I'm sure they're not dished out that often ;). And now we've all learnt something.

I agree with option 3 as the safest. This would be the equivalent of SYSENV/CFG_INET < 1, 3>. So allows for portability for someone moving from that environment. I'm not sure what else you would do in this type of procedure though - maybe send an item to the server's Event Viewer perhaps?

Cheers, M@

DonBakke

Thanks for the response.

FYI, I have modified HTTP_MCP to work along the lines of option #1 above. I wanted to get something in place quickly, even if only for testing purposes. Also, it is very easy to go from option #1 to #2 and/or #3. If you want a copy of what I have created just send me a note at support@srpcs.com. For anybody else, this update will work with version 2.x of the SRP HTTP Framework if you are also interested. Otherwise, you can wait until the final version is updated and officially made available.

Matt, please note that I am not formatting this with HTML the way INET_ABORTED would. This is because the framework is oriented toward API responses, not browser-formatted responses. You are, of course, permitted to change it as you see fit, but I wanted you to know that I did not forget to wrap it.