As of the 5.1 update you've introduced a serious issue in to Request.CreateResponse.
If you return Request.CreateResponse(HttpStatusCode.OK) (or Accepted or any other success code) and the jquery ajax call is setup something like this:
```
$.ajax({
type: "PUT",
url: url,
dataType: "json",
data: value == null ? null : JSON.stringify(value),
contentType: "application/json; charset=utf-8",
```
even though Request.CreateResponse is returning OK it will fail.
And before you say don't set the dataType to json if it isn't expecting a json response, lots of us have a lot of code that is generic for calling web api, and this isn't feesible because it would then have to know if it should be getting a value response back or not.
Web API used to return "no content" in the headers in the above CreateResponse example with no value, as it should. It now is not.
I would classify this as a massively breaking change that needs to be fixed ASAP and a public stable point release produced to fix it.
If you return Request.CreateResponse(HttpStatusCode.OK) (or Accepted or any other success code) and the jquery ajax call is setup something like this:
```
$.ajax({
type: "PUT",
url: url,
dataType: "json",
data: value == null ? null : JSON.stringify(value),
contentType: "application/json; charset=utf-8",
```
even though Request.CreateResponse is returning OK it will fail.
And before you say don't set the dataType to json if it isn't expecting a json response, lots of us have a lot of code that is generic for calling web api, and this isn't feesible because it would then have to know if it should be getting a value response back or not.
Web API used to return "no content" in the headers in the above CreateResponse example with no value, as it should. It now is not.
I would classify this as a massively breaking change that needs to be fixed ASAP and a public stable point release produced to fix it.