Skip to content
This repository has been archived by the owner on Nov 20, 2018. It is now read-only.

HeaderDictionary can't add existing key #489

Closed
tenor opened this issue Nov 27, 2015 · 5 comments
Closed

HeaderDictionary can't add existing key #489

tenor opened this issue Nov 27, 2015 · 5 comments
Assignees
Milestone

Comments

@tenor
Copy link

tenor commented Nov 27, 2015

The header dictionary won't allow a header that already exists in the dictionary to be added.

            Response.Headers.Add("Hello", new string[] { "One" });
            Response.Headers.Add("Hello", new string[] { "Two" });

The code above will throw an exception on the second addition.
This was permissible in Web API 2.

        //Web API 2 Example
        // GET api/values
        public IHttpActionResult Get()
        {
            var response = Request.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Hello", new string[] { "One" });
            response.Headers.Add("Hello", new string[] { "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.

@davidfowl
Copy link
Member

Why not just call

Response.Headers.Append("Hello", "One");
Response.Headers.Append("Hello", "Two");

@Tratcher
Copy link
Member

FYI: That's the required contract for IDictionary. WebApi didn't implement IDictionary.

Yes, you should use the Append extension for this behavior.

@tenor
Copy link
Author

tenor commented Nov 27, 2015

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.

@davidfowl
Copy link
Member

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?).

@davidfowl davidfowl added this to the 1.0.0-rc2 milestone Dec 3, 2015
@davidfowl davidfowl self-assigned this Dec 3, 2015
@davidfowl
Copy link
Member

I'm moving those extension methods into Http.Abstractions.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants