3

When using HTTPS with IISExpress 10 and VS2015 web api controllers will not send back the ReasonPhrase for a HttpResponseMessage. If I connect through HTTP it works fine, but HTTPS just clears out the reasonphrase. When deployed to azure this doesn't happen (https works as expected), it only happens on my local machine.

You can reproduce this by making a new mvc app with web api support, framework 4.5.2. Create a new web api controller (it will do the same thing with an mvc controller and HttpStatusCodeResult) and add a post command such as:

public HttpResponseMessage Post()
{
    var ret = new HttpResponseMessage((HttpStatusCode)270) { ReasonPhrase = "Test reason phrase", Content = new StringContent("test content") };
    return ret;
}

I used postman to test it. Over http the status will be 

270 Test reason phrase

over HTTPS it will just be

270 OK

You can set a breakpoint and see that ret is being set correctly regardless of where the request comes from, so something in IIS is overriding the ReasonPhrase on HTTPS.

I have tried setting httpErrors in the web.config to pretty much every combination for errorMode and existingResponse. My machine.config (for any version of .net) is not set to retail anywhere. The application.config inside .vs has httpErrors set to overrideModeDefault="Allow".

I cannot think of nor find any other suggestions for settings to modify. Is this just a bug/limitation of iisexpress? Or is there some magic setting I'm missing?

Update:

I made a VM with windows 10 and VS2015 to test. Same results. I also enabled IIS (normal IIS) on the VM and published to it. Same results in that as well.

I also changed the Status Code to 570 just for fun and that gives same results, "570 OK" which I find funny because 5xx is not considered a success code so I would have expected something different than OK.

jneta
  • 55
  • 1
  • 5
  • Hi jneta, I ran into the same issue in Windows 2016 (HTTP will show the correct ReasonPhrase and HTTPS will show OK). It will work in Windows 2012 R2. Our WebAPI may generate 4xx error codes and we want to interrogate the ReasonPhrase to show a better message to the users. I also follow your IIS forum [link](https://forums.iis.net/t/1230186.aspx), over a year ago. Anyone has a suggestion we can try? Thank-you in advance. – K Ling Dec 15 '17 at 03:39
  • Since this seems to be caused by HTTP/2 being used by default in IIS 10, you could try to disable it. https://stackoverflow.com/questions/44660634/how-to-disable-http-2-on-iis-of-windows-server-2016 Note that I have not tried this. I ended up not using ReasonPhrase anymore and just passed messages back with my data. – jneta Dec 16 '17 at 13:32

1 Answers1

2

I ran into the same issue, and it looks like it's due to IIS 10.0 using HTTP/2 along with your browser, which doesn't allow the ReasonPhrase field to be used.

https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2.4

8.1.2.4. Response Pseudo-Header Fields

For HTTP/2 responses, a single ":status" pseudo-header field is defined that carries the HTTP status code field (see [RFC7231], Section 6). This pseudo-header field MUST be included in all responses; otherwise, the response is malformed (Section 8.1.2.6).

HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.

Community
  • 1
  • 1
Lambo Jayapalan
  • 321
  • 5
  • 15