<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I know this has been discussed a few times on this list, but I’d like to throw a different model for decoding headers into the ring. My approach revolves around using the Codable protocols introduced in Swift 4. An example can be found here: <a href="https://github.com/GeorgeLyon/Server" class="">https://github.com/GeorgeLyon/Server</a> / <a href="https://github.com/GeorgeLyon/Server/blob/master/Sources/Server/main.swift" class="">https://github.com/GeorgeLyon/Server/blob/master/Sources/Server/main.swift</a><div class=""><br class=""></div><div class="">This approach is a happy medium between the swift-server/http specifying the headers and allowing the frameworks built on top of this core to be flexible in how they handle header fields. By providing a type, the framework can choose to use a [String:String] representation, or even a [(String, String)]. On the other hand, they could choose to use a Codable type with String values or even specialized types like [HTTPMediaRange] for Accept. Indeed, it may be beneficial for swift-server/http to provide default implementations of various header types like HTTPMediaRange without forcing a downstream framework into using them. These specialized types are however outside the scope of this proposal.</div><div class=""><br class=""></div><div class="">Also, decoding HTTP header fields and decoding JSON are VERY similar tasks, and it would be nice if they used the same underlying Swift mechanism so optimizations can be built once for both. </div><div class=""><br class=""></div><div class="">I can put together a PR if this is something the community thinks is interesting. </div><div class="">- George</div><div class=""><br class=""></div><div class="">P.S. Sorry for the double-mail but I thought this was different enough from my handlers-as-structs proposal that I wanted to separate the responses into two threads.</div></body></html>