<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 4, 2016, at 1:34 PM, Brent Royal-Gordon via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Here's my question: Can we have our HTTP parser use Foundation's existing `URLRequest` and `HTTPURLResponse` types as Swift-facing outputs and inputs? Or are these types too-tightly designed for an HTTP client's needs, and we need different types for an HTTP server? Or are there minor modifications the Foundation team is willing to make in Apple Foundation to extend them for our use case? If we *can* use these types on both client and server, I think that would be ideal—it would allow people to reuse their knowledge and potentially a little bit of code.</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">NSHTTPURLRequest and NHTTPURLResponse should be written in terms of a richer HTTP message object. I would suggest NSHTTPMessage => { NSHTTPRequestMessage, NSHTTPResponseMessage } with a class method to parse and construct.</div><div class=""><br class=""></div><div class="">(Currently, NSURLRequest carries a reference to any payload, while NSURLSession expects the payload to be separate from the request header. NSURLResponse doesn't provide the response as a data, and I don't like having the two not be reflexive.)</div><div class=""><br class=""></div><div class="">There's two reasons for this: (1) The current API doesn't allow for correct behavior for multiple HTTP Headers. If you Set-Cookie: a=x and Set-Cookie: b=x, asking for the Set-Cookie header will give you SetCookie value of "a=x; b=x", which is not a valid cookie. There may be other headers for which this combining is incorrect.</div><div class=""><br class=""></div><div class="">(2) CFHTTPMessageRef in CFNetwork implements the underlying behavior here, but that object is not exposed in Foundation. I don't know if CFHTTPMessage ever made it out into the CFNetwork open source drop of, what 2003? but it could do with a refresh. </div><div class=""><br class=""></div><div class="">That being said, the header parsing is pretty trivial. (Except where it isn't, eg multipart-mixed-replace and chunked-encoding Trailers)</div><div class=""><br class=""></div><div class="">--sma</div><div class=""><br class=""></div></body></html>