[swift-server-dev] HTTP Parser

[Brent Royal-Gordon]

> On Nov 4, 2016, at 2:38 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> I did that in a Swift 2 GCD (and http-parser) based iOS HTTP proxy for a customer project. That is, parse stuff into NSURLRequest and NSHTTPURLResponse. I think in general this is the right approach to do this, but I also ran into a few issues. E.g. one was that NSURLRequest takes an NSURL, hence it can’t be used as-is for a `CONNECT host:port …` request.

This may be the kind of thing that needs extension. (As an additional benefit, it would help on the client side, too—client-side URLRequests are equally unable to represent CONNECT method use.)

> And maybe that is the right solution for Swift-Server: Have protocols for that and let the two be just one implementation of them. E.g. a libcurl C request struct could be another. 

Personally, I imagine that libcurl would be handled by translating from `URLRequest` to its preferred structures, but there are different ways to handle that.

> Having said that: there is one detail which may be hard for the API as it may tie into the way the I/O is done: the body streams. In my project I just used the two classes for the headers only.

`bodyStream` is an `InputStream`, so is this an issue if you subclass `InputStream` to represent a socket (or, I suppose, the next Content-Length bytes of a socket)? Or is there some other issue here I'm not thinking of?

-- 
Brent Royal-Gordon
Architechies