Customizing the HTTP Status in Uniface
You might say, this is no problem for you. But think twice. I will explain this in a minute. Have a look at the status code groups:
What should happenDepending upon which event is given, the server returns the fitting code. Talking about Uniface, this allways stays 200. But lets get back to the moment, when something goes wrong. The webserver gets the information about something went wrong and the application tell some code about 5xx which usually says Internal Server Error. This is a clear statement about what has happened. It points to the serving application (in this case Uniface) didn't succeed and aborts.
How this affects usWhile doing AJAX requests you are bound to the return codes from the application. It lets you decide what should happen, if something fails. The User could get informed or an alternative code could be started. So, if you call a Uniface server page or a DSP you wait until the request returns. But you will never figure what happens, if Uniface only tells "http status 200- ok!".
Your code would assume the request to have run as desired and maybe present some Uniface yellow or read screen where the user waits for the aqquired informations! And that's not very nifty!
Forcing UnifaceWithin the Uniface code, everything is straight down the road and controls the output. But I found a simple way to interfere those lines of code.
Try to put this in your EXEC-Trigger or somewhere else in the executed code lines:
Afterwards compile the Uniface Server page (USP or DSP) and enjoy a wonderfull Internal Server Error abort screen :)
What happens ...... is plain simple. Uniface runs our code and feels fine with it. After our component has finished, the returned data has to be transported to the CGI which then feeds the browser. Further Uniface has to tell the Server how the request turned out. As we know, Uniface will give a 200! ... but not this time :) We have changed the status field and override the normal habit.
NOW we can tell the frontend, something went wrong and the AJAX will be able to handle this in a desired way!
A common way of using itIf you at some point want to redirect from the actual component to another one, then we could use some web standards to force this!
I use this, when I need to abort the actual task because somebody needs to log in! :)
Good luck with this. Comments appreciated !
You should always use the right status codes. Studying http://www.w3.org/Protocols/rfc2616/rfc2616.html will help. But remember for authentication and authorization you use the application shell or the get state trigger and return a minus 21 and youll give a 401 network logon error back. Kind regards Frank Sjoukes