Skip to main content
Inspiring
September 17, 2019
Answered

restSetResponse content

  • September 17, 2019
  • 1 reply
  • 2411 views

Well, this is an extremely frustrating function. Especially for produces="application/json"

Depending on what you set the status to, your content is overridden by messages or default templates.

A few test functions:


status 401, 404 return body with html default template instead of specified content

 

 

//test function for 404 - returns html default template
remote void function notfound()
	httpmethod="GET"
	restpath="/not-found"
{
	response = {
		content: "Oops, not found",
		status: 404
	};
	restSetResponse(response);					
}

 

 


status 422 returns body with html "The custom error module does not recognize this error."

 

 

//test function for 422 - returns "The custom error module does not recognize this error."
remote void function UnprocessableEntity()
	httpmethod="GET"
	restpath="/unprocessable-entity"
{
	response = {
		content: "Oops, unprocessable entity",
		status: 422
	};
	restSetResponse(response);					
}

 

 

 
The purpose of having produces="application/json" was to always have the body/content a JSON structure -
which obviously isn't going to happen if my content is ignored. For example -

 

 

//json structure for errors
private Struct function handlerError( required string funcName, required any e)
{
	var funcResp	    = structNew();
        funcResp.error	    = true;
        funcResp.msg	    = ARGUMENTS.e.message;
        funcResp.type	    = ARGUMENTS.funcName & " -> " & ARGUMENTS.e.type;
        funcResp.error_code = ARGUMENTS.e.errorCode;

        return SerializedJSON(funcResp);
}

// should return for 422
{"error":true,"msg":"Oops, unprocessable entity","type":"Unprocessible Entity","error_code":"422"}
// should return for 404
{"error":true,"msg":"Oops, not found","type":"Not Found","error_code":"404"}

 

 


How can I override the override, so my content is returned in the body?
Environment: Windows Server 2012R2 v6.2, CF2016, IIS v8

 

Correct answer BKBK

When you serialize to JSON you essentially get a string. But, here, your function is returning a struct instead. 

So, you should modify the code to something like

 

private String function handlerError( required string funcName, required any e)
{
	var funcResp	    = structNew();
        funcResp.error	    = true;
        funcResp.msg	    = ARGUMENTS.e.message;
        funcResp.type	    = ARGUMENTS.funcName & " -> " & ARGUMENTS.e.type;
        funcResp.error_code = ARGUMENTS.e.errorCode;

        return serializeJson(funcResp);
}

  

1 reply

BKBK
BKBKCorrect answer
Braniac
October 5, 2019

When you serialize to JSON you essentially get a string. But, here, your function is returning a struct instead. 

So, you should modify the code to something like

 

private String function handlerError( required string funcName, required any e)
{
	var funcResp	    = structNew();
        funcResp.error	    = true;
        funcResp.msg	    = ARGUMENTS.e.message;
        funcResp.type	    = ARGUMENTS.funcName & " -> " & ARGUMENTS.e.type;
        funcResp.error_code = ARGUMENTS.e.errorCode;

        return serializeJson(funcResp);
}

  

Sergii Melnykov
Participating Frequently
January 29, 2025

Hello,

This seems relevant as I'm trying to add some AJAX to an existing application, but I ran into the same general issue.

Can I have the same JSON handling when output is done with the following approach?

 

 

getPageContext().getResponse().setStatus(422);
getPageContext().getResponse().setContentType('application/json; charset=utf-8');
writeOutput(serializeJson(data));

 

As implemented above all of the 4xx errors are replaced with corresponding HTML stubs, while code 200 works perfectly. I can have a workaround with the status code in the body, but I wanted to keep it semantical on JS error handler side.
My situation is complicated a little bit by no control over CF settings either directly or via the Application.cfc (and IIS likewise).
Sergii Melnykov
Participating Frequently
January 30, 2025

There you go. That's why I pressed with all the questions. 

 

Yes, what you show is a. Iis-generated page. If cf returns a 405, for example, then iis shows that page you shared.

 

And that's controlled by the iis "error pages" feature, configurable at either the site or server level of iis. You would have a couple options.

 

You could use its "edit feature settings" feature, and change it to show detailed errors to local and remote users.

 

Or you could delete each of the listed "custom error page" links such as that for 405 and so on.

 

Let us know how it goes. 


Oh sure and I appreciate that!

However for now IIS configuration is out of the question (just like anything else outside of the module I'm working on) and hence the case here seemed to have an identical problem (and supposedly has been resolved from within CF!) I gave it a try anyway.