Case-sensitivity for custom HTTP headers in response

[cdaven]

The HTTP specification says that headers are case insensitive (see RFC 2616, section 4.2). .NET parses the basic headers and puts them in the HttpResponseMessage.Headers object, so we don't have to think about this. However, all custom headers are copied to the EntryResponse object by HttpToEntryExtensions.SetHeaders() into a case-sensitive Dictionary.

You can see what I mean in the unit test TestToTypedEntryResponse(), and change this line:

Headers = new Dictionary<string, string>() { { "Test-key", "Test-value" } },

Change e.g. "Test-key" to "test-key", and the test will fail. Is this intended or a bug?

I thought we could make this easy by making EntryResponse.Headers case-insensitive in the constructor:

public EntryResponse()
{
    Headers = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
}

But since Headers is replaced in e.g. ToTypedEntryResponse(), that would have to be refactored as well.

What do you think? The Swedish NLL implementation has suddenly announced that they will start using lowercase headers only.

[cdaven]

Ping @marcovisserFurore. In short: the SDK makes it harder to adhere to the HTTP specification by putting headers in a case-sensitive dictionary.

[marcovisserFurore]

Hi @cdaven, thanks for the ping. I lost focus on this idea. I think you are right and I will convert this idea to an issue and we will put this on the next sprint.

[ewoutkramer]

I have totally revised the FhirClient last year, and I think I have removed all this code, and we are now fully using the .NET HttpRequestMessage and related classes, so we should be much more compliant.

[cdaven]

Yes, the header name in the SetAndExtractRelevantHeaders test is now case-insensitive. Did you add an explicit test for this?

[ewoutkramer]

No I did not! This came for "free" because we are now directly using Microsoft's underlying API ;-)