Custom error message assigned to ReasonPhrase in HttpResponse (defined in the Server) is NOT sent to the client, the client always gets default ReasonPhrase message

Hi All, Does anyone experience the same issue where your custom error message assigned to ReasonPhrase in HttpResponse (defined in the Server) is not sent to the client? For example, In the server, I want to send StatusCode 400 with a custom error message in ReasonPhrase such as “Name is missing” then send it to the client. I would expect to receive that exact custom error message in ReasonPhrase of HttpResponse on the client-side. However, the value of ReasonPhrase in the client is the default one such as “Bad Request” for StatusCode 400.  The weird thing, testing it locally (both Server and Client are local) seems working fine, which means the client-side can receive the custom error message in ReasonPhrase. However, in the case where the server and client are in the cloud, seems the client-side always receive the default error message in ReasonPhrase regardless of whatever custom message defined in ReasonPhrase  in the Server One solution might use the Content instead of ReasonPhrase for defining the custom error message. But I am looking for other solution which can also work without me having to change the current workflow.  Thank you
2 answers

Hi Arief,

The correct place for such a message would be the Content/Body of the response.
The reasons phrase is only a textual representation of the status code, according to:

According to the RFC 7230, the current reference for message syntax and routing in HTTP/1.1, the reason phrase exists with the sole purpose of providing a textual description associated with the numeric status code and a client should ignore the reason phrase content. The RFC also states that the reason phrase can be empty.


Where is your app running, as in which cloud? Mendix Cloud v4 ignores your custom phrases, or most of them, and replaces them with the default ones. And returning a 404 in Cloud v4 is even weirder, try that one yourself.

What I often do is add an object to the body that contains reponse details. There I have an attribute Code duplicating the HTTP response code, and some additional attributes with a reason text, UTC timestamp of the server, etc. That helps me to overcome this cloud-changes-the-reason-phrase issue.