Mail/Login: Password : forgot my password!

Customizing the HTTP Status in Uniface

Direct link
Written by -GHAN- // Tags: http status uniface

Uniface Web is quite simply to manipulate... Every request ends up with the normal http status 200 saying "ok". This isn't changed allthough an error occured. The output will turn yellow or red depending on how critical Uniface feels about it.

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:
Sorry- ... please log-in or register to get this!

What should happen

Depending 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 us

While 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 Uniface

Within 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:
Sorry- ... please log-in or register to get this!

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 it

If you at some point want to redirect from the actual component to another one, then we could use some web standards to force this!
Sorry- ... please log-in or register to get this!

I use this, when I need to abort the actual task because somebody needs to log in! :)

Good luck with this. Comments appreciated !


on 2010-06-24 13:27:34 -GHAN- wrote:

sure that, but always reply [b]200 - OK[/b] cant be right while having a yellow page or even a red one! There is NO chance to catch that with JavaScript while running an AJAX request :) So, there is a good reason to twist this so it can fit into the normal habit. And yes, the response codes should be used wisely.

on 2010-06-22 22:27:46 FrankSjoukes wrote:

You should always use the right status codes. Studying 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

1236 view(s) / 2010-02-26 13:09:51 / LAST UPDATED: 2011-07-13 16:07:23