You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 20, 2018. It is now read-only.
The code above will throw an exception on the second addition.
This was permissible in Web API 2.
//Web API 2 Example// GET api/valuespublic IHttpActionResult Get(){varresponse= Request.CreateResponse(HttpStatusCode.OK);
response.Headers.Add("Hello",newstring[]{"One"});
response.Headers.Add("Hello",newstring[]{"Two","Three"});return ResponseMessage(response);}
In this scenario, Web API 2 adds the header values to the underlying values collection. I think this is the right behavior because that was the developer's intention even though they broke the contract.
The text was updated successfully, but these errors were encountered:
I don't feel strongly either way about this. Append is an extension that is not visible unless I'm already aware of it.
I'm just pointing out that one way breaks a working pattern in older apps, and the other way properly adheres to the IDictionary contract.
This is one of those things that I think needs to change in application code. I think Append could be closer to the actual type since it's a fundamental operation (or is it?).
The header dictionary won't allow a header that already exists in the dictionary to be added.
The code above will throw an exception on the second addition.
This was permissible in Web API 2.
In this scenario, Web API 2 adds the header values to the underlying values collection. I think this is the right behavior because that was the developer's intention even though they broke the contract.
The text was updated successfully, but these errors were encountered: