[swift-server-dev] HTTP Parser

[Tanner Nelson]

I think it's important to remember that performance is not the only concern.

If we need to use the node_http parser because of time constraints, I'd prefer that over creating a non-Swifty copy. If you want the functionality of UnsafePointers, C is the better language to be working in.

Going forward I think a Swifty HTTP parser could get decent performance. More importantly though it would be incredibly concise, readable, and maintainable.

Tanner Nelson
Vapor 
+1 (435) 773-2831

> On Nov 3, 2016, at 2:42 PM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Completely agree Alex, I also feel strongly about the language in general, and I think if we're going to take the time to build out Swift server apis, they should be in well, Swift.
> 
> In terms of performance, Swift will only continue to improve in performance, and given our access to the compiler team and the smart minds in this room. I think we can beat the node parser with time.
> 
> - Logan
> 
> On Thu, Nov 3, 2016 at 2:41 PM Alfredo Delli Bovi <alfredo.dellibovi at gmail.com <mailto:alfredo.dellibovi at gmail.com>> wrote:
> 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 <mailto: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 <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/e2fe0498/attachment.html>