How do you control Response body output in INavigable with when response code is not a 200

Is this a custom route and is it a page, file, json/xml response?

It's a custom REST API that implements INavigable because it needs to allow for anonymous users to call it.  But the behavior varies depending on the user's role, so in some cases I need to kick back an error.  All calls should return application/json, except one which returns text/csv.  For the text/csv, I just want to return some plain text, like "Unauthorized".  For the application/json, it would be something like { "Errors" : [ "Unauthorized" ] }.  (or whatever the error actually is).  But, if the response code should be 401, I'd like to see that rather than a 500.

If you are not already, you should be  adding it as a Raw route, and do not use RestException.  That is meant to be used in REST which is a different infrastructure.  Really you don't need to throw an exception at all.    You should be able to do what you are doing, set the status code and end the response.

Note I really wouldn't add error at all, treat RAW routes like HttpHandlers and add the status, output, etc to the response yourself.

This is how I'm adding the routes...

Here's where I'm writing the error output:

Here's the behavior I'm seeing:

If the status code is set to a 401, I end up getting a 302 with a Location header redirecting to the Login page.

Other status codes end up outputting properly.

What happens if you Flush the response stream and call Response.End?

On a side note, you say anonymous users are able to call this, so is a 401 really ever a valid response?   401 should be authentication is required but anonymous access would not apply.  If credentials aren't required, a 403 is probably more appropriate. 

On a side note, you say anonymous users are able to call this, so is a 401 really ever a valid response?   401 should be authentication is required but anonymous access would not apply.  If credentials aren't required, a 403 is probably more appropriate. 

Ya, and that works, so I may just use that approach and write a 403 instead.

If I had to guess based on some simple searches, the 401 might redirect way down in the framework based on its nature