[swift-server-dev] HTTP Parser

[Alfredo Delli Bovi]

Hi people,

There has been some discussions about this in Kitura already (https://github.com/IBM-Swift/Kitura-net/issues/52 <https://github.com/IBM-Swift/Kitura-net/issues/52>) and I think we can use what they found out at the moment.
In my opinion, if we are not able to give the same (or better) performance we should go for a wrapper of a more performant lib, such as http_parser.

Of course it’s also matter of the workload that have, we could always start with a wrapper, so we are able to define the APIs layer and ship a version with it and later on changing the implementation with a pure Swift.

—
Alfredo Delli Bovi 

> On 3 Nov 2016, at 19:35, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Helge, definitely depends on the underlying network/dispatch scheme that we go with. I doubt we'd pull in my original code 1:1. But it does speak to my experience w/ the RFC spec in particular.
> 
> I'd personally opt for pure-swift over c-wrapper. I think it will be easier to maintain/deploy/optimize going forward. I don't have an inherent problem w/ the nodejs parser aside from that if people strongly prefer to use c-code here.
> 
> - Logan
> 
> On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> wrote:
> Hi Logan,
> 
> On 03 Nov 2016, at 17:50, Logan Wright <logan at qutheory.io <mailto:logan at qutheory.io>> wrote:
> > Yup, you can see a lot of it in the underlying engine module from Vapor.
> 
> is it this one?:
> 
>   https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift <https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift>
> 
> that seems to be a pull based / blocking parser, right? That probably doesn’t work for a lot of environments.
> 
> 
> Personally I’d suggest a small wrapper around this one:
> 
>   https://github.com/nodejs/http-parser <https://github.com/nodejs/http-parser>
> 
> It is small, fast, highly efficient, zero copy, push based, supports chunked&upgrade and is extremely well tested and widely deployed.
> 
> 
> I also did a straight port of that to Swift, though if you can use the C version I wouldn't use the port as it is significantly slower (and may have extra bugs introduced during the port):
> 
>   https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser <https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser>
> 
> My approach here was to keep it close to the original, which makes for really ugly code :-)
> I think it may be worthwhile to do another attempt of a port of the parser, but less 1:1 like mine, in a Swiftier way (the original uses a lot of goto’s :-).
> 
> 
> As mentioned, I wouldn’t expect people to use the low level API but rather have nice objects filled by the underlying parser. What about `WORequest` & `WOResponse`? :-)
> 
> 
> BTW: Something I consider important to discuss across all areas of interest (crypto, sockets, HTTP) is a protocol to represent a chunks of bytes and chunks of chunks of bytes (buckets and brigades in Apache terms). Of course that could be just NSData or DispatchData but I expect that some frameworks have their own way to represent such buffers, hence a protocol would be nice.
> Why important? Well, because there needs to be a way to pass the data between those components w/o copying it :-)
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161103/f189f04e/attachment.html>