We are excited to announce that the IIS.NET Forums are moving to the new Microsoft Q&A experience. Learn more >

IIS 10: Setting of custom Response.StatusDescription on HTTP2 is ignoredRSS

3 replies

Last post Jun 28, 2016 10:50 AM by uid156079

  • IIS 10: Setting of custom Response.StatusDescription on HTTP2 is ignored

    Sep 15, 2015 03:20 AM|ClintGono|LINK

    IIS team,

    It looks like setting the Response.StatusDescription property has no effect.

    For reference, the web application which I am running is on:

    ASP.NET 4.5.2
    IIS 10/Windows 10

    To reproduce this issue, I'm attaching two pieces of code.

    FIrst is the filter that I have set up that captures exceptions from my MVC actions:

        public class HandleUIExceptionAndReturnJSONAttribute : FilterAttribute, IExceptionFilter
            public virtual void OnException(ExceptionContext filterContext)
                if (filterContext == null)
                    throw new ArgumentNullException("filterContext");
                if (filterContext.Exception != null)
                    filterContext.ExceptionHandled = true;
                    filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
                    filterContext.HttpContext.Response.StatusCode = (int)System.Net.HttpStatusCode.BadRequest;
                    var ex = filterContext.Exception;
                    while (ex.InnerException != null)
                        ex = ex.InnerException;
                    filterContext.HttpContext.Response.StatusDescription = ex.Message;

    And the controller:

        public class TestController : Controller
            public ActionResult Test()
                throw new ApplicationException("The 400 request means that we stop");

    The expected HTTP status code is: 400 The 400 request means that we stop

    The resulting response is: 400 Bad request (Firefox) or 400 OK (Opera)

  • Rovastar Rovastar

    5495 Posts



    Re: IIS 10: Setting of custom Response.StatusDescription on HTTP2 is ignored

    Sep 15, 2015 02:18 PM|Rovastar|LINK

    This does look like an ASP.NET forum question but

    For 400 error codes you cannot generate a custom response within IIS at least (I don't think that has changed in IIS10)

    Troubleshoot IIS in style
  • Re: IIS 10: Setting of custom Response.StatusDescription on HTTP2 is ignored

    Jun 23, 2016 05:47 AM|uid156079|LINK

    You are wrong in several points:

    In all IIS implementations so far we could change the StatusDescription for the HTTP Status Codes and this is still the case, if IIS 10 answers with HTTP/1.1 instead of HTTP/2.0.

    So we have the following scenario in IIS, for  IIS 10 changes HTTP version itself, when Server and Client agree to use TLS:

    If the clients supports TLS it receives HTTP/2.0 with an IIS defined StatusDescription (HTTP/2.0 400 Bad Request).

    If the client does not support TLS or calls via http, it receives HTTP/1.1 with a customized StatusDescription (HTTP/1.1 400 My error message).

    Second mistake:  this is not an ASP.NET question, for all modern Web Application, that use ajax requests depend on the possibility to send a customized error message back to the caller through the ajax response of XMLHttpRequest (XHR). So most currently existing ajax enabled Applications (asp.net or not) will fail on IIS 10 when switching to HTTP/2.0.

    But as you suggested previousliy, I will post this to ASP.NET forum too and link back to here, hoping both teams will find a solution together: http://forums.asp.net/t/2097804.aspx?HTTP+2+0+in+IIS+10+0+does+not+allow+change+of+StatusDescription+of+HttpStatusCode+response

  • Re: IIS 10: Setting of custom Response.StatusDescription on HTTP2 is ignored

    Jun 28, 2016 10:50 AM|uid156079|LINK

    I apologize for my unjustified criticism above!

    After reading RFC 7540 about HTTP/2, I understand that we can not use StatusDescription ("reason phrase") in HTTP/2.

    Section " Response Pseudo-Header Fields" of RFC 7540 says: HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.

    My second mistake: it is not IIS 10, that produces the response status line "HTTP/2.0 400 Bad Request", but the client (browser), that enhanced a simple 400 from IIS with its own information.

    Unfortunately the problem persists, that probably many web applications will be broken.