{"id":28551,"date":"2020-04-03T16:48:16","date_gmt":"2020-04-03T20:48:16","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=28551"},"modified":"2020-04-03T16:51:23","modified_gmt":"2020-04-03T20:51:23","slug":"swift-bridging-of-allheaderfields","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/04\/03\/swift-bridging-of-allheaderfields\/","title":{"rendered":"Swift Bridging of allHeaderFields"},"content":{"rendered":"

Cédric Luthi<\/a>:<\/p>\n

\n

I don’t do a lot of swift. But every time I do, I stumble on obscure quirks. Last case in point: HTTPURLResponse<\/code> allHeaderFields<\/code> is now case-sensitive<\/a>.<\/p>\n<\/blockquote>\n

This seems to be because the property is implemented using an NSDictionary<\/code> subclass. Apple<\/a> notes:<\/p>\n

\n

In Objective-C, the returned dictionary of headers is case-preserving during the set operation (unless the key already exists with a different case), and case-insensitive when looking up keys.<\/p>\n<\/blockquote>\n

But Swift bridging converts it to a regular Swift Dictionary<\/code>, which is case-sensitive (though looser about Unicode).<\/p>\n

In general, you can avoid the bridging by casting:<\/p>\n

allHeaderFields as NSDictionary<\/pre>\n
In this particular case, there is an extra API<\/a> in Catalina and iOS 13 to look up header fields in a case-insensitive way:<\/p>\n
func value(forHTTPHeaderField field: String) -> String?<\/pre>\n
This is an interesting case study of the current Cocoa documentation because:<\/p>\n