We recently received a complaint from one of our customers. We provide some fairly simple reporting functionality, that allows more technical users to write their own SQL queries. The customer was building a report and when there was a problem with his SQL, sometimes he’d get a detailed error message, but other times he’d get nothing.
When we try to execute a query and an exception is thrown we catch the exception and write the error message to HttpResponse.StatusDescription so it can be displayed in the browser. This can fail if the message is longer than 512 characters long, but this is fairly obvious since setting the StatusDescription property will throw an exception. That clearly wasn’t the problem here.
I finally managed to reproduce the problem but was still confused about what was causing the issue. Then I spotted the difference between the working case and the non-working case. The non-working case contained new line characters. Thinking about it, this was fairly obviously going to be a problem. The HTTP response would not be valid, since the status description header would be split over two lines. But it would certainly be preferable if .NET threw an exception in this case, rather than just silently failing to set the status description.
So our code now looks something like this
context.Response.StatusCode = 500; context.Response.TrySkipIisCustomErrors = true; string description = ex.Message.Replace('\n', ' ').Replace('\r', ' '); if (description.Length > 512) description = description.Substring(0, 512); context.Response.StatusDescription = description; context.Response.ContentType = "text/plain"; context.Response.Write("An error occurred - " + ex.Message);
