We are using the Swisscom CloudFoundry solution with a Java and a Node.JS application. Since very recently, every HTTP status code starting with 5xx (tested with 500 and 503) is automatically mapped to the status code 302 Found with a redirect header to /offline_pages/ (tested with DELETE, POST and GET). This is done in-between our application and the front-end, requesting a resource with a status code 5xx.
We are actively using the 5xx status codes to report a server error to the front-end over our REST API (including maintenance down-time etc.). This does not work anymore, because of the automatic mapping. For instance, there is no automatic redirect to a maintenance page anymore, because the front-end does not see 3xx status as an error.
This issue occurs in both our applications (Java and Node.JS). The logs, however, display the correct 503 respectively 500 error. Furthermore, in our application's code base the redirect URL string /offline_pages/ is not even present; which leads to the conclusion, that this must be done outside of our application.
If a visible browser page returns a 500 the user is actually redirected to the page /offline_pages which displays a Swisscom error page. This error page (to which it redirected), then returns a 200 status code on its part, making it impossible to automatically detect the error in a Kiosk browser.
Is there any possibility to configure the Swisscom CloudFoundry to deactivate this behavior, which is suddenly occurring?
This is the request made by the front-end:
GET /api/account HTTP/1.1
Host: <HOST>
Connection: keep-alive
Accept: application/json, text/plain, */*
User-Agent: <USER-AGENT>
Referer: <REFERER>
Accept-Encoding: gzip, deflate, br
Accept-Language: <LANGUAGES>
And this is the response:
HTTP/1.0 302 Found
Location: /offline_pages/
Connection: Keep-Alive
Content-Length: 0
Excpected is the same as in the server logs, in this case a 503. Here are the logs for this request:
2017-11-14 13:54:07 [RTR/1] OUT <HOST> - [2017-11-14T12:54:07.455+0000] "GET /api/account HTTP/1.1" 503 [...]
There has been a reconfiguration of Swisscoms load balancer that caused this weird behavior. It should be fixed now.