While I don't agree that it should behave this way (the 503), I think I know what is going on.
When a connection is made to the GUI, the GUI process needs to start up and connect to the coordinator. This can take a few seconds, and the script at the login page has a four second time out. Once the connection is made, then you get the 200 OK and are presented with the log in prompts.
I don't know much about What's Up, but could you configure it to check again in 4-5 seconds after getting a 503? That should be sufficient time for things to settle.
Thank you for your answer Andy
currenty we configured the WhatsUp to check for https://proxy:4712/ and 302 response, which should be enough to check the mwg-ui process is alive.
after little searching I found that 503 can be complemented with a Retry-After header, which describes the exact this situation:
The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.
Andy is right, at the moment we send the wait page with an 503 as long as the GUI backend is initializing, once this is done we send the 200 to indicate that the user can "login".
Using the "Retry-After" header for future versions should not be an issue.
Would that be ok for you?
is the backend initializing a heavy operation? Do I create an additional load on the MWG by triggering it or I better to stick with https://proxy:4712/ and getting (but not following) 302 Redirect to https://proxy:4712/Konfiguration/request ??
because if I get 302 I know the mwg-ui is alive, it will be enough information for the monitoring.
The bigger the pilicy is you store, the bigger is the operation in terms of CPU and memory consumption.
The backend loads all needed data and keeps most of it in memory. Normally the backend is shut down again after all users have logged out (and no one tried to login within ~30 seconds).
If you get the 302 redirect you know that the backend is alive.
If there would be an fatal error, which would lead to errors within the mwg-ui (e.g. mwg-ui initialisation failed due to totaly broken policy) you would only see this if you init the backend (
https://proxy:4712/Konfiguration/request) and get an 500 (Internal Error) response code.
Nevertheless, MWG has other possibilities to inform administrators that something has gone wrong. So I guess ony checking if the redirect works should might be enough.
Yes, sorry, copy-pasted from your post.